[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gEDA-user: OR components screwed on postscript output



[ I'm cross posting this geda-dev only because it is related to development
  work.  Sorry. -Ales ]
  

>so I scratched everything and I am trying to get 20010304 to
>build/install.
>
>One problem with libgdgeda/libgeda:
>
>in the configure script, libgdgeda is tested before png and zlib, and thus
>libgeda does not build on my system because to test for libgdgeda the test
>has to link with -lpng.
>It seems to me it would be more logical to test first for zlib, then png,
>then gdgeda. Attached is a diff to libgeda/configure.in.


	Agreed.  I think I was _not_ thinking when I wrote that.

>
>Also, it seems to me that in the various configure.in files, the line:
>LDFLAGS="$LDEXTRA `$GTK_CONFIG --libs` -lgtk -lgdk -lglib $LDFLAGS -lm"
>causes problems on systems (like FreeBSD) where the various libs may have
>been renamed. After all, why use glib-config or gtk-config, and then
>manually add -lgtk -lglib ? changing this to 


	Good question.  I think I was trying to kludge something.  If those
libraries can be removed, then that's fine.


>LDFLAGS="$LDEXTRA `$GTK_CONFIG --libs` $LDFLAGS -lm"
>helps here. I think it is better to not hardcode lib names, but to either
>provide a switch to override a defaulted variable.

	Sounds good.


>
>It would be good to be able to specify additional path to search for libs
>and include files, currently I just hardcoded them in the configure.in

	
	Okay.


>
>Finally, there is a typo in gnetlist/configure.in relative to the glib
>command-line option to configure. diff attached.

	
	Great.  Thanks.  I'll integrate this tomorrow as my fingers are 
giving up on me tonight.  Unless somebody beats me to it.


>
>I hope my comments are useful and will allow to improve the build system
>to make it more platform independent. I'll happily test any new version
>and changes.


	Thanks for the comments, feedback, and patch.

								-Ales