gEDA-user: scons

[al davis <ad136@xxxxxxxxxxxxxxxx>]

> On 2/28/07, al davis <ad136@xxxxxxxxxxxxxxxx> wrote:
> > The only place I see for broadcast bounties I see is to get
> > something new.  I have been considering offering a bounty
> > for someone to make a good quality replacement for
> > autotools.  It's even on GNU's list of needs, but they want
> > to do in in guile which is a mistake.  It must be written
> > entirely in "make" and /bin/sh.
>
On Wednesday 28 February 2007 17:45, Samuel A. Falvo II wrote:
> As I understand things, the Guile solution is aiming to not
> only replace autotools, but also make itself.  Since Guile is
> a proper, Turing-complete language, this makes sense.

The problem (please correct me if I am wrong) is that it creates 
a dependency on guile.  Someone needs guile to work on a 
program that doesn't use guile anywhere else.

Lots of languages are "Turing-complete".

I like "make" because it is a logic language ... a list of 
rules, and what to do when the rule applies.

> But, there *already* is such a system in existance, called
> SCons.  I have some experience with SCons, and I really,
> really like it.

I looked at the web page ..  It looks like the files are python 
scripts.  ok .. now we have a dependency on python.  Someone 
needs python to work on a program that doesn't use python 
anywhere else.

> SCons apparently has scalability problems, which is why KDE
> is switching/has switched to CMake, which looks interesting
> too, but still suffers from relying on Make.

and it has some of the same bizarre syntax that autotools/m4 
have.

> The problem with Make comes from *nesting* sub-projects
> within a larger context. 

If they are truly sub-projects I want to be able to work on them 
separately.  completely separately.  You can do this with 
recursive makefiles.

With autotools, this is broken.  It uses recursive makefiles, 
but flat configuration.  A combination that gives you the 
disadvantages of both with none of the advantages of either.

> As long as you use a flat Makefile 
> (which references sub-projects explicitly via relative
> pathnames), then that singular makefile will have everything
> it needs to do exactly what's needed. Otherwise, you end up
> wasting a lot of effort in building and maintaining a
> package.

The effort I put into the makefiles non-autotools version of 
gnucap has been near zero, even when I make big changes.

> I'm curious to learn if CMake builds a single makefile or
> not.

I don't want a single makefile.



_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user