gEDA-dev: Re: gEDA-user: scons

[Peter TB Brett]

On Thursday 01 March 2007 05:11:59 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 ... make is not that default either, 

Um...yes it is!

<snip>

> Finally, portability: as mentioned above, I don't really believe that
> autotools can save one from having #ifdefs for some portability problems
> at the end. However, I hate to be interrupted in the code, either when I
> write it or when I read it, by huge chunks of #ifdef HAVE_* code. It
> really affect readability if you can't concentrate on _what_ the code does
> but you have to read trough _how_ it is done on specific systems. So in
> gpmi we decided to separate these issues into os_dep.c/os_dep.h; I'm so
> happy with this scheme that I tend to follow it in other projects as
> well. The idea is to create a compatibility layer which has all the
> ifdefs. For example we have gpmi_path_init() call there, which sets up
> some basic paths: on windows using the registry and using backlashes, on
> UNIX using the prefix info got from Makefile (and indirectly
> configure) and slashes. We need to do foobar but that is done differently
> in BSD and in windows? We just add a foobar() in os_dep. Sometimes it's
> just a wrapper to call the same functions with different names for
> different systems or to rearrange the call arguments, sometimes the whole
> logic differs.

This is always a good idea.  (Apart from using the registry, that's always a 
bad idea :P ).

> Yes, this is definetly reinventing the wheel. For example Apache has a
> nice compatibility lib or actually even automake offers solving the
> porting problem. I am sure automake knows more systems than I do, and I am
> also sure Apache devs know more about porting than me. Still, if one of my
> aims is to keep things small and simple, I simply shouldn't reuse their
> work. Sometimes reusing existing work/code saves time, sometimes it wastes
> time :)

On the other hand, you now have a vast collection of custom scripts that 
*no-one* coming to the project from outside has a hope of understanding fully 
without a serious investment of time and effort.  If someone has a problem 
building GPMI due to a bug in your configuration system, they're unlikely to 
invest the time required to fix it themselves (even if its well within the 
realms of their expertise), meaning that you get a bug report rather than a 
patch, for instance.

When the libgeda rewrite gets underway, I'm hoping to use glib more 
extensively for portability -- I'm a big fan of reusing other people's work 
where appropriate!

Cheers,

Peter


-- 
Fisher Society committee                    http://tinyurl.com/o39w2
CUSBC novices, match and league secretary   http://tinyurl.com/mwrc9
CU Spaceflight                              http://tinyurl.com/ognu2

v3sw6YChw7$ln3pr6$ck3ma8u7+Lw3+2m0l7Ci6e4+8t4Gb8en6g6Pa2Xs5Mr4p4
  hackerkey.com                                  peter-b.co.uk
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://www.seul.org/pipermail/geda-dev/attachments/20070301/b8661ab6/attachment.pgp