apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: cvs commit: apr/user/unix .cvsignore Makefile.in
Date Thu, 11 Jan 2001 04:11:29 GMT
On Wed, Jan 10, 2001 at 07:13:36PM -0800, rbb@covalent.net wrote:
>...
> > I'm just going to punt that stuff. Ryan made a change to allow us to tell
> > apps to include libmm.la, so that should be fine. That will also keep us
> > from poking around with the MM files, making assumptions about .lo
> > organization, etc ... much cleaner.
> > 
> > The whole copy thing used to be in there, but was an artifact of the old
> > system. I think we can clear it out.
> 
> Okay, I'm confused, and I've been gone for about a day and a half, so I'm
> going to ask.  Forgive me.  :-)
> 
> Greg, I thought you said that the solution I added was wrong.

Not that I recall. There was a solution that Jeff posted from Allen which I
thought was wrong.

Your export of the LIBTOOL_LIBS is fine. It is always possible that we'll
have more in the future.

The one issue about exporting libtool libraries is when the user of APR
doesn't use libtool. That hasn't come up yet, but it certainly will. For
that case, we would need the user to install APR first (thus installing the
.a and/or .so files), so the user can link against whatever file.

[ note that your exposure of libmm.la isn't the cause: once we libtool'd
  APR, then we already have the issue since we build libapr.la ]

> Or, did
> you mean that the stop-gap you used was wrong, and mine was right?

I whacked something in there, but didn't get a chance to fully test it. When
I compiled/linked Apache later in the day, I saw the mm_ link errors and
knew my quick conversion was wrong. By then, you and Jeff were already on
it, and you checked in a valid solution.

> I did
> what I needed to get it working, but I am perfectly open to new solutions.

It works for me. 

I only have two mild concerns:

1) APR's use of .la files when the user doesn't use libtool (noted above)
2) APRVARS.in using variables not in the APR namespace. See apr-util's
   export_vars.sh.in for what I think is the Right Way (and how it is used
   in Apache's configure.in). By using unprotected names in APRVARS, we
   might "stomp" on the user's vars.

I've got no immediate answer for (1), and (2) is just something that has
been in mind for a while. I'll get around to it at some point, probably
after JimJag's flag revision stuff.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Mime
View raw message