automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [CRAZY PROPOSAL] Automake should support only GNU make


From: Stefano Lattarini
Subject: Re: [CRAZY PROPOSAL] Automake should support only GNU make
Date: Fri, 14 Jan 2011 19:21:54 +0100
User-agent: KMail/1.13.3 (Linux/2.6.30-2-686; KDE/4.4.4; i686; ; )

On Friday 14 January 2011, Steffen Dettmer wrote:
> On Thu, Jan 13, 2011 at 8:39 PM, <address@hidden> wrote:
> >  ``I truly dislike the idea of not keeping configuration and build
> >   steps separated.''
> >
> > Maybe I'd just like a system that *allows* me to keep configuration
> > and build steps clerarly distinct if I want to.  Yes, that would
> > be enough for me I guess.
> 
> Maybe it is just a matter of terms, but I think the concept of
> "configuration" (as software configuration) is only about
> deciding which configure option to set or not to set; the
> configure run itself IMHO does not need to be separated from
> the rest of the building.
>
Oh, I see your point now.  And I agree that your more granular view
might be useful and sensible.

BTW, when one starts thinking in these terms, a new terminology is
probably needed -- one that separates "software configuration" (e.g.,
setting of install directories, enabling/disabling of features,
etc.) from "requirements checks" (e.g., determining if and where an
external library or program is available, if the compiler supports
a determinate type, and so on).

> >> Wouldn't it be great to type "make" which automatically knows by
> >> depedencies that some configuration rules have to be executed
> >> (i.e. to determine facts about the environment if they are not
> >> available in form of small .h files or alike)?
> >>
> > Yes, but then, this could be implemented by having the build system
> > call the configuration system properly, no?  More or less like is
> > done by automake-generated rebuild rules, just "on steroid" I guess.
> 
> Yes, except that automake->autoconf rules implement a "phase" or
> "stage" idea: when a "configure run" is needed, it is performed
> entirely.  So it can be seen as separated where the build system
> can trigger the "configure run".
>
> >> If, for example, Makefiles would have rules to check for the
> >> libraries as soon as needed etc, wouldn't this be good?
> >> Tests that are not needed for the configuration to be built
> >> would not even be executed (saving time).
> >>
> > What do you mean exactly by this?
> 
> I'm not sure if this makes any sense, but I could imagine that if
> some file conditionally (enabled by some
> configure-as-in-software-configuration option) uses some feature
> which in turn depends on a platform function that has to be
> checked, then in this moment this single test could be performed.
> Let's say I used some --enable-tcp switch. The build system finds
> that in this case it needs tcp.o. By some depedency tcp.o depends
> on some have_socket_h.check_result file. The creation rule for
> this file invokes a test for <socket.h> and stores the result,
> which is used by tcp.o building in some way.
> 
> If no networking would be used, this check would not even be
> executed. The test result is just an input like a BUILT_SOURCE or
> so.
> 
> Maybe this would work in some way.
> 
> oki,
> 
> Steffen
> 
> 
Thanks for the explanation, this makes sense now.  And you have
definitely good points.

Just a couple of clarifications about what I think:

 - A user might want to run all the "requirements checks" before
   starting to build the package (otherwise, what if the build
   process punts halfway because a dependency is missing?).  So
   he must be offered this possibility (and it should probably
   be made the default).

 - All the results of the "requirements checks" should be
   user-overridable.

Regards,
  Stefano



reply via email to

[Prev in Thread] Current Thread [Next in Thread]