Warren Young wrote:
> I outlined a situation in this message where they would:
Quoting from that post:
> say that the requirement for bakefile and its prerequisites (Python
> and SWIG are the most odious) is no longer just my problem.
SWIG is not one and Python is shipped as part of Windows package and
is only required as external dependency on Unix, where it's more
likely to be already installed than not nowadays.
> Yes, the state of the docs concerns me, too. Too many FIXMEs and
> too much hand-waving.
Not sure what you mean by "hand-waving", but yes, the docs are heavily
incomplete and so is the code -- there's a reason why the version is
0.1.x and I would be the first one to caution against using bkl to
generate non-trivial makefiles. But other people are apparently
already able to use it, so your mileage may vary.
> Some things I don't see addressed in the
> - Do its generated makefiles have the ability to make both debug and
> release binaries at once, and keep them separate?
It's akin to asking if GNU make has this ability and the answer is
same: if you write your makefile (bakefile) that way, yes, if you
don't, no. It is definitely possible and there's even a template
("preset" in bkl speak) for doing exactly that...
> - Can it handle our new library soname scheme?
It doesn't use libtool, so -version-info flag can't be used, and it
doesn't use libtool-like versioning scheme yet, but it gives you the
ability to set the soname directly as x.y.z.
> - Do the MSVC targetted-Makefiles require nmake?
Yes. It's native makefiles generator and so it generates makefiles for
native tools, which in the case of MSVC is nmake (or the IDE).
> - Does it create a 'dist' target?
> - Does it make a proper 'install' target?
As far as I can tell, it does -- wxWidgets is installed that way. It's
more low-level than in Automake currently, though -- the headers are
installed explicitly using a rule to copy them.
PGP key: 0x465264C9, available from http://pgp.mit.edu/