On Sun, 23 Sep 2001 16:13:54 -0700
Greg Stein <gstein@lyra.org> wrote:
> On Sun, Sep 23, 2001 at 02:03:55PM -0700, Mo DeJong wrote:
> >...
> > > 3) Change the INSTALL targets so they do a cd before installing.
> >...
> > I decided to take a shot at implementing option #3 since it seems the most simple course
> > of action. This patch will do a cd to the directory in question before calling libtool to
> > actually do the install. I have double checked it and this works around the problem
> > without having to patch libtool or any generated files.
>
> Cool.
>
> > The one catch is that this
> > patch will need to be merged with Greg's other patches by hand since it changes
> > the same lines.
>
> Not a problem. I can just merge it into my code base and then resubmit the
> patch.
Great.
> >...
> > ofile.write('\ninstall-mods-static: %s\n'
> > '\t$(MKDIR) %s\n'
> > - % (string.join(la_tweaked + s_files),
> > - os.path.join('$(APACHE_TARGET)', '.libs')))
> > + % (string.join(la_tweaked + s_files), '$(APACHE_TARGET)'))
>
> Stop screwing around with the .libs for the static install. I don't recall
> where I said it, but you can't just remove the .libs stuff here. That is a
> *target* directory that we're constructing. This isn't a reference to our
> own .libs. You're just blindly removing references to .libs, and it is wrong
> in this case.
That was why I mentioned the need for a hand merge.
> But no matter... I'll get the "cd" stuff incorporated into my WC here,
> tested, and then resubmit a patch to the list.
>
> Note that submitting the patch to the list is merely for people to try out.
> I'm not sure that we want to switch over to it just yet. I had a bitch
> trying to find a pair of libtool and autoconf RPMs. And the autoconf RPM had
> a bug in it(!). (go to rpmfind.net and you'll see the lack...)
I don't know about RPMs, but the source is not hard to find.
ftp://ftp.gnu.org/gnu/autoconf/autoconf-2.52.tar.gz
ftp://ftp.gnu.org/gnu/libtool/libtool-1.4.2.tar.gz
> What I'm saying is... converting to the new autoconf/libtool might be neat,
> but I think it will mostly just cause a pain for developers trying to get
> the most recent packages.
>
> That said, I might look into seeing how we can support *both* versions of
> autoconf and libtool. APR is at that point right now, and I see no reason
> that we couldn't do the same (although, it is harder for us, as an app).
That would be a big mistake. We already talked about the tradeoffs here.
Upgrading to autoconf 2.50 and libtool 1.4 solves a lot of problems. It
also provides some features that are not currently easy to do (like
cross compiling). Requiring that developers have the most recent
stable release of autoconf and libtool is not too much to ask. I am
not going to claim that everyone will be happy, but I do claim that
upgrading now will lead to less unhappiness in the long run. If you
try to support two build systems, it will lead to many wasted man
hours hunting down bugs that may be caused by incompatibilities
between the old and new version of autoconf and libtool. It will only
take a developer 5-10 minutes to build and install the most current
stable releases of autoconf and libtool.
cheers
Mo
(old thread that talks about this)
http://subversion.tigris.org/servlets/BrowseList?listName=dev&by=thread&from=2548
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:42 2006