Re: gEDA-user: scons

[Igor2 <igor2@xxxxxxxxxxx>]

On Thu, 1 Mar 2007, Dan McMahill wrote:

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

<snip>

>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.

Yes, and this is the drawback: gpmi depends on bash and gnu make.

>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.

Yup, you can't totally ignore portability. On the other hand, casting
pointers to ints is a bad habbit, even if you don't plan to port the
stuff. What I learned and what I wanted to suggest: keep the code clean in
general (no ptr->int casts, do not depend on sizeof(int), do not depend on
undocumented "features") _and_ move all #ifdef chunsk in named high level
procedures. 

>> 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.

Yes, again, we do depend on bash and the script starts with #!/bin/bash
not with #!/bin/sh. This is a dependency, as if the script was in python
or m4.

>> 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.

Sorry, I can't get this one. Configure script runs without assuming on
what system you are on - it rather tries to discover the
system. Autodetecting script libs is part of this. When you are packaging,
you expect the software can be easily installed so you can copy/move the
installed files into the package. We can build .deb, .msi and .rpm
currently and we didn't have hard time doing them because the lack of
autotools. For example debian/rules runs configure make and make install,
and it doesn't need to have any custom ways.

Igor2




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