Hi,
I have two constituencies here; people who would like to see
guile support in make, and to explore the new features. And people who
expect a sensibly small set of packages essential to building other
packages in Debin.
Without guile suport, make just depends on libc, and nothing
else. Guile support adds the allowing packages to the dependencies:
guile-2.0-libs, libgc1c2 (>= 1:7.2d)
Since make is build essential, I am not going to pull in these
extra dependencies without due consideration, so I have put the
wishlist bug to add the support as wontfix, for the moment. However,
just install guile-2.0-dev, apt-get source make, and rebuilding should
give you a guile supporting make, so it is a low barrier of entry. I
have labeled wontfix a bug report to prevent that from happening,
since that would change the behaviour of make compiled on a machine
(not a sterile build environment) somewhat different than the official
package. I suspect that there are a lot of things in the environment
that could change the resulting binaries, which is why most
deterministic build scanarios start with a well defined build
environment; and in such an environment the current make package will
indeed build consistently without guile support (unless build-essential
or debhelper grow guile dependencies, and I';; of course watch for
that). But, enough rambling.
How do we move forward with enabling guile support in make?
Building two binary packages from a single source seems hackish,
since make and make-guile would require ./configure to be run again,
and each target of the ./debin/rules might need cleanup/restart. Not
unsolvable, but messy, and I do not have the motivation to do
that. Patches welcome, of course.
I would like to solicit the opinion of the developers about the
value of adding Guile support to the default make package, at the
expense of two smallish additional dependencies.
http://blog.melski.net/2013/11/29/whats-new-in-gnu-make-4-0/ has a
write up on what guile support would bring.
Thanks for listening
manoj
--
Perl itself is usually pretty good about telling you what you shouldn't
do. :-) --Larry Wall in <11091@jpl-devvax.JPL.NASA.GOV>
Manoj Srivastava <srivasta@acm.org>
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C
Attachment:
signature.asc
Description: PGP signature