[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: gEDA-user: scons

Igor2 wrote: 
On Wed, 28 Feb 2007, al davis wrote:


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. 


<snip>

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.



Completly true, however bash or make is not that default either, however I
prefer project which have simple configure/make. Somehow I find it
annoying to have an 500k long configure script to create Makefiles for a
program that finally will end up only 200k itself.

bash is not always there by default but /bin/sh _is_. And it's not that hard to write shell scripts which are portable. As far as make is concerned, you can usually count on having some make implementation around. The trouble is that there are lots of make extensions which are all non-compatible. My take here is if you have to rely on some extra feature it should be in GNU make just because many users have already had to install GNU make for other packages.

It's always a hard thing to decide: use custom written
configure/make/compatibility stuff or use autotools. Autotools offer that
your program will run on systems you have never seen without needing to
care too much about portability while coding. Still I often find ifdefs
for system-specific things in projects using autotools... So when we had
the same problem with libgpmi, we decided to use custom solutions.

I would argue that this is not true at all. You still need to write portable code. In my mind, the biggest thing autotools bring are a) a consistent way to configure and build and b) some framework to help figure out if required dependencies exist and c) a framework for running tests to deal with differences in OS that you can't avoid by just writing more portable code.

I've seen plenty of packages that use autotools that try to store pointers in ints. Not portable but worked on x86-linux. Of course it fails on an alpha or x86_64. I've seen plenty of packages that for one reason or another cared about byte order. Those tended to fall into 2 categories, the ones that had a broken homebrew detection and those which used the autoconf test and got it right.



The configure script is a shell script (unfortunately depends on bash,
not sh). It's modular: there's a huge (20k) central script that

well, so there is problem #1. bash is only there by default on linux. So step #1 on solaris would be "figure out why the configure script won't run, install bash". Unfortunately I run into this all the time and often times it is simple stuff like using "==" instead of "=" in lines like

if test "$x" == "$y"; then ...

Of course I see people put non-portable stuff like that in configure.ac as well.

way). General settings (like prefix or whether an option is enabled or
not) are simple shell variables during the configuration and some of them end up in an includable Makefile and in an includable shell file so later
other Makefiles or scripts can use settings without running the whole
configure process again. There's a shell file that has the default
settings for all these variables with rich comments; the comments are
structured in a way that a small script (<7k) can present a menuconfig
using dialog(1) - it looks like menuconfig of the Linux kernel, with
nested submenus. The user can use --with arguments for the configure
script or use a local.conf file where he can modify any of the
variables (note that this file is a shell script so he can build some
basic logic here).

which means that 3rd party packaging systems which might build things automatically have to have their own custom ways of configuring the tool. Granted it is probably not hard, but it just adds up for those trying to maintain a large number of packages.

-Dan


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