[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