Re: svn commit: r798326 - in /apr/apr-util/branches/1.3.x: CHANGES build/rpm/apr-util.spec.in

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

minfrin@apache.org wrote:
> Author: minfrin
> Date: Mon Jul 27 23:16:21 2009
> New Revision: 798326
> 
> URL: http://svn.apache.org/viewvc?rev=798326&view=rev
> Log:
> Make sure the LD_LIBRARY_PATH is sensible when running the tests
> from the RPM build, so that the crypto, dbd and dbm tests pass.
> Ensure the dbm module is packaged up correctly in the RPM.

-0.5, can you clarify why this isn't true from the Makefile itself?
This just didn't seem like a rpm-specific quirk.

Re: svn commit: r798326 - in /apr/apr-util/branches/1.3.x: CHANGES build/rpm/apr-util.spec.in

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Graham Leggett wrote:
> William A. Rowe, Jr. wrote:
> 
>> Irrelevant.  ./testall wasn't built for execution, make check was built
>> for execution.
> 
> Then why didn't you just say so in the first place instead of sending me
> on a wild goose chase?

What wild goose chase?  You never even asked a question.  You just solved
a 'bug' you thought nobody had ever pondered before :)  The answers are
all in the archives.

At one time, these flags were different, and they were changed for a
specific purpose, and the archives and svn(cvs) logs tell all.

Re: svn commit: r798326 - in /apr/apr-util/branches/1.3.x: CHANGES build/rpm/apr-util.spec.in

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Graham Leggett wrote:
> 
> I have absolutely no idea why we've reinvented automake inside our build
> scripts. I have absolutely no idea why we are trying to feed libtool
> weird platform specific flags that make macosx and linux work entirely
> differently from one another, and I am very interested to hear why this
> is currently justified from someone who does understand this mess.

What does automake have to do with this?  Other than adding sufficient
abstraction to render the build schema useless on anything but linux.

Bill

Re: svn commit: r798326 - in /apr/apr-util/branches/1.3.x: CHANGES build/rpm/apr-util.spec.in

[Graham Leggett <mi...@sharp.fm>]

William A. Rowe, Jr. wrote:

> Irrelevant.  ./testall wasn't built for execution, make check was built
> for execution.

Then why didn't you just say so in the first place instead of sending me
on a wild goose chase?

The ./testall comes out of the ages old Redhat spec file, and I have no
idea why it is like that and quite frankly I don't care - I am only
interesting in getting to work properly right now the right way,
whatever the right way is.

I have absolutely no idea why we've reinvented automake inside our build
scripts. I have absolutely no idea why we are trying to feed libtool
weird platform specific flags that make macosx and linux work entirely
differently from one another, and I am very interested to hear why this
is currently justified from someone who does understand this mess.

Regards,
Graham
--

Re: svn commit: r798326 - in /apr/apr-util/branches/1.3.x: CHANGES build/rpm/apr-util.spec.in

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Graham Leggett wrote:
> William A. Rowe, Jr. wrote:
> 
>> -0.5, can you clarify why this isn't true from the Makefile itself?
>> This just didn't seem like a rpm-specific quirk.
> 
> On MacOSX, libtool does the right thing, and ./testall is a script that
> picks up the right libraries from the right place. On Linux, ./testall
> is the final binary, and so only picks up libs from LD_LIBRARY_PATH.

Irrelevant.  ./testall wasn't built for execution, make check was built
for execution.  And the Makefile check: target illustrates how to run
this.  -1 (binding, veto) for an RPM-specific hack.  Nothing that is
produced from make; make check; make install should be altered by the
rpm process; you obviously screw non-rpm, linux users in the process.

> It looks like this is caused by a flag called "-no-install" which is
> passed to libtool, and I find this hard wired into configure.in:
> 
> # Use -no-install to link the test programs on all platforms
> # but Darwin, where it would cause the programs to be linked
> # against installed versions of libapr instead of those just
> # built.
> case $host in
> *-apple-darwin*) LT_NO_INSTALL="" ;;
> *) LT_NO_INSTALL="-no-install" ;;
> esac
> AC_SUBST(LT_NO_INSTALL)
> 
> So, anyone know who put this there, and why?

Because you do not want the destination RPATH as recorded in the binary,
you want the LD_LIBRARY_PATH (or LIBPATH or SHLIB_PATH).  Because you
may test before install, while installing over an existing tree, using
the installed flavor would be fatal.

Re: svn commit: r798326 - in /apr/apr-util/branches/1.3.x: CHANGES build/rpm/apr-util.spec.in

[Graham Leggett <mi...@sharp.fm>]

William A. Rowe, Jr. wrote:

> -0.5, can you clarify why this isn't true from the Makefile itself?
> This just didn't seem like a rpm-specific quirk.

On MacOSX, libtool does the right thing, and ./testall is a script that
picks up the right libraries from the right place. On Linux, ./testall
is the final binary, and so only picks up libs from LD_LIBRARY_PATH.

It looks like this is caused by a flag called "-no-install" which is
passed to libtool, and I find this hard wired into configure.in:

# Use -no-install to link the test programs on all platforms
# but Darwin, where it would cause the programs to be linked
# against installed versions of libapr instead of those just
# built.
case $host in
*-apple-darwin*) LT_NO_INSTALL="" ;;
*) LT_NO_INSTALL="-no-install" ;;
esac
AC_SUBST(LT_NO_INSTALL)

So, anyone know who put this there, and why?

Can anyone explain, given we use autoconf and libtool already, why we
aren't using automake? Or is it a case of it was just always like this?
A simple Makefile.am makes all of this go away, in theory.

Regards,
Graham
--