On Thursday, 05 April 2007 at 10:15, David Champion wrote: > * On 2007.04.05, in <20070405104227.GE6560@xxxxxxxx>, > * "Christoph Berg" <cb@xxxxxxxx> wrote: > > > > > > No, it almost certainly won't be installed on (say) a NetBSD system. > > > (And neither will perl) > > > > It is only used at build time. (And perl has been required for > > running smime_keys for a long time.) > > The systems on which you need to build mutt are the ones that are least > likely to have python already installed, for the same reasons. > > I'm comfortable with saying you need perl/python to run an adjunct > program to use S/MIME (it's like saying you need GnuPG to use OpenPGP) > but saying you need it to compile the software is a little more > demanding. > > Two ideas: > * If it can be done *reasonably* without external interpreters, then > that makes sense. If not, there could be a fallback in mutt code > itself that provides less smart versioning for builders without > python. I'm not too keen on having a less-smart versioning option. I think it'd make bugs harder to diagnose. I would be willing to convert the script to perl or shell/sed/awk, but I'm very rusty in those. Maybe someone else can do it? > * Or: distributed source bundles can just include hcversion.h, and we > say that python is required to build developer versions from scratch. > I don't see any issue with that. We already require GNU make and > autoconf/automake for developer builds, and we already use this > policy-over-technology approach on other issues. I like this idea and had intended to do it this way at first, but some of the structures are affected by configure options (at least --enable-exact-address). > Three comments: > * "$(CPP) -include" looks like a gcc-ism > * $^ looks like a gmake-ism. Better to avoid if possible, but > as above, not terrible if hversion.h is bundled on distribution > to avoid gmake dependency for non-devel builders. > * Should we think about using only one external interpreter -- > settling on perl or python, but not both? (I'd vote python, > with whatever script adaptations/rewrites this implies.) I'd vote python too, but I don't think I've got the cycles to convert perl now, especially since my perl is so rusty. > I'm not sure what $^ is, but I assume it's the dependency list. yes. > Perhaps instead of this: > hcversion.h: $(srcdir)/mutt.h $(srcdir)/rfc822.h > $(CPP) $(AM_CPPFLAGS) $(CPPFLAGS) -include config.h $^ | python > > we could try something like this: > hcversion.h: $(srcdir)/mutt.h $(srcdir)/rfc822.h > ( \ > echo '#include "config.h"; \ > echo '#include "mutt.h"; \ > echo '#include "rfc822.h"; \ > ) | $(CPP) $(AM_CPPFLAGS) $(CPPFLAGS) -I. -I$(srcdir) | python Looks good, I'll do it that way.
Attachment:
pgpoSxxa7gVmM.pgp
Description: PGP signature