On Feb 9, 2009, at 10:28 PM, Toby Peterson wrote:
On Mon, Feb 9, 2009 at 7:12 PM, Bradley Giesbrecht
<[email protected]> wrote:
I am familiar with -d. Been running it all day.
I have tried to find a way to influance the configure script without
patching but I gave up and patched it.
# port configure // fails
# cd work/libzdb-2.3/ && ./configure --prefix=/opt/local // works
As far as I know --prefix typically influences the install dir and
not the
finding of libs or includes.
But I'm not a strong unix admin.
Just try the scripts I attached. Takes about a minute or two to add
them to
a local repo.
I have the scripts dumbed down on purpose. Running ./configure with
no args
(or with prefix=/opt/local if you prefer) from ${worksrcdir} or
what ever
that var is named works.
Running "port configure" does not work.
OK, I see why it doesn't work. This was mentioned previously. We set
LDFLAGS/CPPFLAGS (and other variables) in the environment, which
breaks the following command:
mysql_config5 --libs $LDFLAGS
Normally LDFLAGS is empty, so it doesn't affect this. Anyway, easy
enough fix to patch-configure ....
+ LDFLAGS=`/opt/local/bin/mysql_config5 --libs $LDFLAGS`
+ CPPFLAGS=`/opt/local/bin/mysql_config5 --include $CPPFLAGS`
should be
+ LDFLAGS=`/opt/local/bin/mysql_config5 --libs` $LDFLAGS
+ CPPFLAGS=`/opt/local/bin/mysql_config5 --include` $CPPFLAGS
That should get things working, to some extent. I have some other
complaints about your Portfile, but let's get this thing compiling
first. :)
Yes, you and Ryan both had this figured correctly. It's now compiling.
Thanks.
I had reduced the Portfile to it's bare minimum in my attempt to find
what was wrong.
Should I make variants for sqlite, mysql and postgresql or just let
the configure script look for all three and fail with a message if it
finds nothing?
I also planned on adding a couple configure options like these three:
--enable-optimized Build software optimized
--enable-zild Reduce visbility of objects for linking
with zild.
Require gcc version 4.x
--enable-protected Package protect non-api objects. Require gcc
version
4.x This option hide objects in
the DSO which are
not part of the api and not to
be exported. The
rationale is to optimize the
ABI and protect
non-public methods of the DSO
and thereby reduce the
potential for namespace
conflicts for clients
linking with the library.
Recommend
//Brad
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
