[Bf-committers] making things a little more generic
Wed, 15 Jan 2003 04:40:28 +0100 (CET)
On Tue, 14 Jan 2003, John K. Walton wrote:
> On Tue, 14 Jan 2003, Hans Lambermont wrote:
> > Would that work for you ? (I hope it does, it does for me ;-) I use it
> > for make -> gmake as well)
> yes, it would work, but i would refer all customization to be
> at the system level, rather than user 'hacks'. JMO!
I've got entire trees set up to deal with this kind of thing, and it
does drive me bonkers. I used to have /usr/local/bleedingedge/bin in my
path for projects that required versions unsupported by my revision of
FreeBSD, but I gave up on that when I wound up with two projects that
required conflicting Perl stuff, both bleeding edge, none cooperating.
So now I have /usr/local/<project>/bin with symlinks to the tools needed
for <project>. Blargh.
I think a project like Blender is doomed if it doesn't set minimal
requirements, like "you must use version X of autoconf or be prepared
to deal with the damage". I'd be disappointed if Blender required me to
have bash installed, but if the requirement were clear from the outset
I'd bite the bullet and install it, rather than try to work around the
glitches that might be caused by its unavailability.
It's a trade-off. You want the most portable code and support
infrastructure to lure in as many developers as you can, but you don't
want to live in #ifdef hell when it comes to dealing with autoconf, gcc
Two cents from Mr Workaround.
Bert Driehuis -- email@example.com -- +31-20-3116119
If the only tool you've got is an axe, every problem looks like fun!