Chris Frey wrote:
>
> If the end user has to install Bakefile
This could in fact be the case.
The least intrusive option is to use bakefile to replace only makemake.
In that case, almost nobody but me needs to know about bakefile.
Bakefile can also generate autoconf-compatible Makefile.in, so we could
also use it to replace automake. Just a single source to edit appeals
greatly to me, of course.
One consequence is that the bootstrap script would depend on bakefile.
Several times over the past year I've had to recommend that people run
the bootstrap script for one reason or another. (I did it again today,
in fact.) If I took this second step, then it would be reasonable to
say that the requirement for bakefile and its prerequisites (Python and
SWIG are the most odious) is no longer just my problem.
Another place where the use of bakefiles can create a requirement on the
user community is when someone wants to contribute something like a new
top-level target, like Chris's ebuild target. Then they have to go
learn the bakefile syntax. I get a lot of push-back already on the
requirement to learn regular make syntax....
> In reading the Bakefile website, it seems like it is the second option,
> but I'm not sure from the documentation.
Yes, the state of the docs concerns me, too. Too many FIXMEs and too
much hand-waving. Some things I don't see addressed in the docs:
- Do its generated makefiles have the ability to make both debug and
release binaries at once, and keep them separate?
- Can it handle our new library soname scheme?
- Do the MSVC targetted-Makefiles require nmake?
- Does it create a 'dist' target? That wraps up a lot of knowledge
about what files go into a tarball, and is extensible with EXTRA_DIST.
I'd hate to lose this feature.
- Does it make a proper 'install' target? Automake lets you declare
things like some headers are installed, while some are not, for instance.
Still, I have to say, moving to Bakefile is more tempting to me than
starting work on the automake-to-VS project file converter I proposed.
