Re: gEDA-dev: Re: gEDA-cvs: CVS update: ChangeLog

[Dan McMahill <dan-at-NOSPAMmcmahill_dot_net>]

Ales Hvezda wrote:
> Hi Dan,
> 
> [snip]
> 
>>How about disabling libgd always then unless it is requested?  The 
>>current state is one of my gripes about autoconf.  It's one thing to 
>>test for and enable work arounds, but I really don't like it when 
>>optional components get compiled in or not compiled in via an automatic 
>>decision.  In fact explicitly doing --enable-gd won't fail, it will just 
> 
> 
> 
> 	I don't understand your gripe.  If a library is present, then 
> libgeda (for example) includes support for it (for example libgd).  
> If a library is not present and it is optional, then libgeda warns the
> user and then continues on (either substituting builtin code or disabling
> the support completely).   I must be missing something really obvious.

It's because the user has to pay a lot more attention to the configure 
output if they care about the optional libs and because it can introduce 
unrecorded dependencies that take a while do uncover in packaging systems.


>>emit a warning in the middle of a ton of other messages, if gdlib isn't 
>>installed.
>>
>>Right now building with the exact same configure arguments and exact 
>>same everything but with and without gdlib installed produces 2 
>>different compiled results with 2 different sets of dependencies.  I 
>>find that confusing and also it makes it somewhat more painful for 3rd 
>>party package maintainers.  For example, you build geda without gdlib 
> 
> 
> 	Painful how so?  If it is, this is the first I've heard of this
> problem from any package maintainer.
> 
> 
> 
>>installed, everything looks good but you don't notice that there is no 
>>png export.  You build a package.  Now someone builds on a system with 
> 
> 
> 
> 	Ah but libgeda/gschem include builtin png support so the user 
> does still get png support it just behaves (slightly different png output)
> a little bit differently.

ah.  I missed that bit. That makes me feel better.  Time for a stupid 
question on my part.  Why is gdlib ever used then?


>>gdlib installed but perhaps no dependency is registered and later gdlib 
>>is removed.  Now you have a broken geda.
> 
> 
> 
> 	Well, if a user removes a component that some other program 
> (built from source) is using, there is very little anything can be done
> to prevent breakage.  Users building things from source are on their own;
> they should be using a package manager if they want this to all work.
> It is up to the package manager software (dpkg, rpm, etc...) to maintain
> order and discipline in such cases IMHO.


So someone sets up a packaging system which builds from sources.  They 
list gtk and other required libs as dependencies but don't list gdlib. 
They test it out and all is well.  Now some user with gdlib installed 
also uses this packaging system (using the source package created by the 
first user) to build the package.  The packaging system doesn't know 
that gdlib now magically shows up as a dependency because the creator of 
the package didn't have gdlib as a dependency.  Now the 2nd user goes to 
remove gdlib, the packaging systems says that nothing depends on it but 
the automatic decision by autoconf has added a real (and not recorded) 
dependency.


> <silly mode>
> 	So, are you suggesting that ./configure not enable gtk+ and
> the user should enable that (using a command line flag) before libgeda
> ./configure runs successfully?  Why should required vs optional dependancy
> checking work differently?  
> </silly mode>

I'm suggesting that it would be silly for configure to detect that gtk 
is missing and go ahead and build a gaf system where you could only do 
batch mode operations (yeah, I know that this isn't even possible right 
now, but the point is to not make automatic decisions about features and 
dependencies).

My take is optional dependency means there is a user hook to turn it on 
or off but once that decision has been made by the user, the concept of 
"optional" should be gone.  In other words if I say "--enable-gd", I 
don't want the configure system to interpret that as "use gd if it was 
found but just skip it if it wasn't there".  I want configure to 
interpret is "I want gd, period."  Just like with --disable-gd, I don't 
the configure system to decide "well, but there is a working gdlib here, 
lets use it anyway even though the user said not to".  Of course right 
now it is only --enable-gd which is only taken as a suggestion while 
--disable-gd is taken as a commandment.


At least --disable-gd works.  It would be really evil to do the optional 
linking with no controls at all.


See "automatic decisions" in 
http://www.onlamp.com/pub/a/onlamp/2005/03/31/packaging.html?page=2
for some more thoughts on this.  Personally, I'm a believer in option #1 
that Julio gives although he seems to prefer #2.  If option #1 is 
followed I think when some some optional component is on by default, 
then error out when it isn't found but give an explicit message saying 
what configure option will make the error go away but what you'll lose 
by doing so and what corrective action to take if you want this option.

Anyway, I'll live with what ever direction you want to take on this.  It 
is certainly not the end of the world ;)


-Dan


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