SCons build, help needed

[Alexander Botero-Lowry]

> Hi,
> 
> How about using gmake instead of scons?
Usually people pick scons because of preceived problems in the auto* system
there are a _million_ articles on that issue if you care to read them, just
search for autohell on google or something like that. SCons just doesn't really
provide a sutible build system replacement, just a suitable make replacement.

Waf is an interesting project [1] if you're interested in seeing SCons done
better.

Alex

1 http://freehackers.org/~tnagy/bksys.html
> 
> Tz-Huan
> 
> On 11/29/06, Alexander Botero-Lowry <alexbl at freebsd.org> wrote:
> > > Alex, thanks for your reply. stiv @ blender forums pointed me to the
> > > sixth paragraph in the SCons' manual:
> > >
> > > "scons does not automatically propagate the external environment used to
> > > execute scons to the commands used to build target files. This is so
> > > that builds will be guaranteed repeatable regardless of the environment
> > > variables set at the time scons is invoked. ..."
> > Which is just _absurd_ and horrible. It makes it nearly impossible for
> > operating systems to legitimately package these applications and it makes
> > for users having applications build in ways that are unexpected and unwanted.
> > This is one of the larger reasons that XMMS2 is moving towards waf. We've had
> > to put a lot of pain into making ourselves integrate well with the various
> > packaging systems because of this attitude.
> >
> > >
> > > I don't know how do they want to integrate with other build tools, but
> > > the current mechanism in bsd.scons.mk is left at the mercy of each SCons
> > > user. What do you think?
> > >
> > What bsd.scons.mk implements is the common case, most SCons using ports that
> > bother to obey external environment at all follow these patterns;
> > CCFLAGS/CXXFLAGS/LINKFLAGS/PREFIX sometimes LIBPATH/CPPPATH passed on command
> > line to scons (not as part of the external environment). It's called like:
> > scons CCFLAGS="-O2".
> >
> > So bsd.scons.mk is implemented in a way that gets in many scons using ports
> > (not all). So the answer to ports that don't obey this pattern is to make them
> > do so.
> >
> > Alex
> > _______________________________________________
> > freebsd-ports at freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-ports
> > To unsubscribe, send any mail to "freebsd-ports-unsubscribe at freebsd.org"
> >
> 
> !DSPAM:4,458925e7491186602915650!
> 
>