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: Steffen Dettmer
Subject: Re: [CRAZY PROPOSAL] Automake should support only GNU make
Date: Fri, 14 Jan 2011 14:14:11 +0100

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.

>> 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



reply via email to

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