[EMAIL PROTECTED] writes:
> gstein 01/01/09 03:06:29
>
> Libtool-ize APR.
> Index: Makefile.in
> ===
> RCS file: /home/cvs/apr/shmem/unix/Makefile.in,v
> retrieving revision 1.14
> retrieving revision 1.15
> diff -
Jeff Trawick <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] writes:
>
> > gstein 01/01/09 03:06:29
> >
> > Libtool-ize APR.
> > Index: Makefile.in
> > ===
> > RCS file: /home/cvs/apr/shmem/unix/Makefile.in,v
> > retr
On Wed, Jan 10, 2001 at 02:52:05PM -0500, Jeff Trawick wrote:
> Jeff Trawick <[EMAIL PROTECTED]> writes:
>
> > [EMAIL PROTECTED] writes:
> >
> > > gstein 01/01/09 03:06:29
> > >
> > > Libtool-ize APR.
> > > Index: Makefile.in
> > > =
> > > > --- Makefile.in 2000/11/15 11:50:07 1.14
> > > > +++ Makefile.in 2001/01/09 11:06:15 1.15
> > > ...
> > > > + cp $(MM_OBJS) .
> > >
> > > Isn't this copying the wrong (or not enough) files? It currently
> > > copies just the .lo (timestamp) files. Maybe it
Nope, Greg didn't like my patch :)
'cause I simply did more monkeying around to get things working.
Victor
--
Victor J. Orlikowski
==
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
On Wed, Jan 10, 2001 at 07:13:36PM -0800, [EMAIL PROTECTED] 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
>
> 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 Apach
On Wed, Jan 10, 2001 at 09:22:30PM -0800, [EMAIL PROTECTED] wrote:
>
> > 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
> >ex
[EMAIL PROTECTED] writes:
> Can I suggest a possible solution for 1, and agree 100% with 2? The
> possible solution, is to use two variables, LIBTOOL_LIBS, and
> NON_LIBTOOL_LIBS. These names are probably wrong, call they what you want
> to.
I guess I'm naive in wishing that an APR user using l
> > Can I suggest a possible solution for 1, and agree 100% with 2? The
> > possible solution, is to use two variables, LIBTOOL_LIBS, and
> > NON_LIBTOOL_LIBS. These names are probably wrong, call they what you want
> > to.
> >
> > The idea is that if you use LIBTOOL, you have to add the librar
> > Can I suggest a possible solution for 1, and agree 100% with 2? The
> > possible solution, is to use two variables, LIBTOOL_LIBS, and
> > NON_LIBTOOL_LIBS. These names are probably wrong, call they what you want
> > to.
>
> I guess I'm naive in wishing that an APR user using libtool could
>
[Note: My connectivity is quite limited currently.. ]
> Somewhat... but it does mean that we'd be looking down into .libs for the
> libraries to put into NON_LIBTOOL_LIBS. Not sure what I think about that
> one... (reaching into .libs is the basic question: do we or don't we?)
Am I correc
> > Somewhat... but it does mean that we'd be looking down into .libs for the
> > libraries to put into NON_LIBTOOL_LIBS. Not sure what I think about that
> > one... (reaching into .libs is the basic question: do we or don't we?)
>
> Am I correct in assuming that the point of those variables
13 matches
Mail list logo
