Re: [lucy-dev] Compiler flags

[Nick Wellnhofer <we...@aevum.de>]

On 21/12/2012 18:15, Marvin Humphrey wrote:
> Heh, generating Makefiles wasn't the approach I was thinking of. :)  I meant
> writing actual build scripts in C.

Ah, I see. That's of course possible, but I think this can't be 
implemented in plain C89 (the up_to_date part, for example). So we'd 
have to run charmonizer first to configure the build script code, making 
the whole thing a two-step process.

Another advantage of Makefiles is that they're more hackable if 
adjustments are needed. If someone wants to make changes to the build 
script, he has to alter the charmonizer C code and regenerate 
charmonizer.c. This requires a lot more insight into how the build 
system works than simply changing the generated Makefile.

GNU make also offers nice features like parallel builds which would be 
hard to recreate.

I'm not really against the build script idea, but I think it's a lot 
more effort than generating Makefiles.

>> * Windows is probably the first platform that will break because of overlong
>>    command lines (8K limit).
>
> At some point we'll probably need to start generating scripts like
> ExtUtils::CBuilder does to address that problem.

Under nmake, there's also a very simple solution using "inline files" 
(kind of like here-docs in a Makefile).

> If we want to generate Makefiles using Charmonizer, I suggest we do something
> similar faking up inheritance with structs.
>
>      struct chaz_PosixMakefile {
>          struct chaz_Makefile base;
>          /* ... */
>      };

Maybe we don't even need separate "classes" for different make 
implementations. Most of the differences depend on the compiler and 
shell type.

> I'd hope we could stay away from parsing a template file (a la "Makefile.in"),
> because having to support parsing would complicate things a lot.

Yes, that was my idea as well.

> I'd argue against generating Makefiles.
>
> Makefile syntax is obtuse on its own, but the real problem is that generating
> Makefiles essentially means compiling down to shell code.  We do pretty well
> compiling down to C with the Clownfish compiler, but C compilers exhibit a lot
> less variability than shells and the external programs that they reference.
> Our task is made harder by the fact that we're contemplating targeting at
> least two shell environments -- POSIX-compliant sh and cmd.exe -- which means
> rearranging arguments, dealing with different quoting and splitting rules,
> invoking completely different commands, etc.

But doesn't the build script approach also mean to execute shell 
commands in the end? I don't really see the difference except for things 
like deleting files (make clean).

Using Makefiles to build a C project also seems like the most natural 
approach to me. As you wrote somewhere else, users generally expect to 
run "./configure && make && make install".

Nick