RFC: Makefile refactoring

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

RFC: Makefile refactoring

Sam Varshavchik
Right now, apps that build against libwww link against about a whole bunch
of libs that are listed by "libwww-config --libs".  It's quite a mouthfull.

That's how most apps are built.  Perhaps it's just my personal taste, but I
always thought that it's much cleaner and simpler just to link a single
library.

I've modified the Makefile to combine all component libraries into a single
libtool target, libwww.la.  As far as I can tell, the Makefile correctly
handles all optionally-built submodules.  That is, if --open-ssl is
specified, libwww.la will include the SSL-related module, etc.

I'd like to get a feel for what others think about this idea.  If there's
interest then I can submit the patch -- probably after the currently-pending
code is released, so that I can resync against the released version.

I should also clarify that my changes aren't really that drastic.  All the
existing components (libwwwhttp.la, libwwwmime.la, and the rest) get still
built, they're just noinst_LTLIBRARIES, and don't get installed.  Instead,
lib_LTLIBRARIES consists of a single libwww.la, which is built by merging
all the individual component libraries.  So, if someone's working on some
code outside of the tree that manually links to a subset of all those
component libraries, that'll continue to work.

The Makefile also builds another consolidated target libwwwconvenience.la,
which is a libtool convenience library.  libwwwconvenience.la will be very
useful to apps that include the entire libwww tree into the apps' source
tarball bundle, instead of requiring an existing libwww install to be made
prior to building the source (like Amaya).



attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Makefile refactoring

Arthur Smith

Fewer library files (or just one) would be a little nicer - I've
certainly had occasions where I accidentally left off one of the
libraries and then was wondering what went wrong. No strong feelings on
this though.

          Arthur

Sam Varshavchik wrote:

> Right now, apps that build against libwww link against about a whole
> bunch of libs that are listed by "libwww-config --libs".  It's quite a
> mouthfull.
>
> That's how most apps are built.  Perhaps it's just my personal taste,
> but I always thought that it's much cleaner and simpler just to link a
> single library.
>
> I've modified the Makefile to combine all component libraries into a
> single libtool target, libwww.la.  As far as I can tell, the Makefile
> correctly handles all optionally-built submodules.  That is, if
> --open-ssl is specified, libwww.la will include the SSL-related
> module, etc.
>
> I'd like to get a feel for what others think about this idea.  If
> there's interest then I can submit the patch -- probably after the
> currently-pending code is released, so that I can resync against the
> released version.
>
> I should also clarify that my changes aren't really that drastic.  All
> the existing components (libwwwhttp.la, libwwwmime.la, and the rest)
> get still built, they're just noinst_LTLIBRARIES, and don't get
> installed.  Instead, lib_LTLIBRARIES consists of a single libwww.la,
> which is built by merging all the individual component libraries.  So,
> if someone's working on some code outside of the tree that manually
> links to a subset of all those component libraries, that'll continue
> to work.
>
> The Makefile also builds another consolidated target
> libwwwconvenience.la, which is a libtool convenience library.  
> libwwwconvenience.la will be very useful to apps that include the
> entire libwww tree into the apps' source tarball bundle, instead of
> requiring an existing libwww install to be made prior to building the
> source (like Amaya).
>
>


Reply | Threaded
Open this post in threaded view
|

Re: RFC: Makefile refactoring

Vic Bancroft-2

Arthur Smith wrote:

>
> Fewer library files (or just one) would be a little nicer - I've
> certainly had occasions where I accidentally left off one of the
> libraries and then was wondering what went wrong. No strong feelings
> on this though.
>
> Sam Varshavchik wrote:
>
>> I'd like to get a feel for what others think about this idea.  If
>> there's interest then I can submit the patch -- probably after the
>> currently-pending code is released, so that I can resync against the
>> released version.
>
Yea !   This sort of work can proceed in two directions.  It sounds like
you have nailed down the first.

The second would be providing some aid in using just a part of the
library function and only pulling in the required parts . . .

more,
l8r,
v


--
"The future is here. It's just not evenly distributed yet."
 -- William Gibson, quoted by Whitfield Diffie


Reply | Threaded
Open this post in threaded view
|

Re: RFC: Makefile refactoring

Sam Varshavchik
Vic Bancroft writes:

>
> Arthur Smith wrote:
>
>>
>> Fewer library files (or just one) would be a little nicer - I've
>> certainly had occasions where I accidentally left off one of the
>> libraries and then was wondering what went wrong. No strong feelings
>> on this though.
>>
>> Sam Varshavchik wrote:
>>
>>> I'd like to get a feel for what others think about this idea.  If
>>> there's interest then I can submit the patch -- probably after the
>>> currently-pending code is released, so that I can resync against the
>>> released version.
>>
> Yea !   This sort of work can proceed in two directions.  It sounds like
> you have nailed down the first.
>
> The second would be providing some aid in using just a part of the
> library function and only pulling in the required parts . . .
Well, a shared library is a shared library.  It's a single hairball, an "all
or none" deal.  If you link against it, you're going to pull in the entire
library at runtime.

What you want to do is link against the static library, so that you only get
what you need, and the flip side is that it's going to be a part of your
executable, and not shared with anyone else.

In this situation a single static library (as opposed to a dozen+ static
libraries you have now) is even more convenient.  You do not need to figure
out all their interdependencies, and which ones you need to link against.  
Just one static library, link against it and you're going to get only the
code you need.



attachment0 (196 bytes) Download Attachment