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

[Ales Hvezda <ahvezda-at-NOSPAMseul_dot_org>]

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.


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


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


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

	Clueless,
		-Ales



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