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
