On Friday 14 January 2011, Steffen Dettmer wrote: > On Thu, Jan 13, 2011 at 8:39 PM, <stefano.lattar...@gmail.com> 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
