Re: [A-A-P-develop] On :lib and :dll

[Bram M. <Br...@mo...>]

Adriaan de Groot wrote:

> Now that we agree that using { filetype } on programs is a useful
> addition, perhaps we can think the same thing through for libraries.
> Right now we have :lib and :dll, both of which build libraries, where
> the compile commands for each of the objects are slightly different,
> and where the final buildlib step differs as well. Could we integrate
> these and write
> 
> :lib foo : foo.c	# defaults to a static library
> :lib bar { filetype=dll } : bar.c	# explicitly a DLL/DSO
> 
> instead?

Why would you want to build a shared library this way?  It's not
simpler than using ":dll".

Don't forget that ":program", ":lib" and ":dll" are shortcuts to produce
a certain kind of target.  It makes it easy for the user to specify how
a specific kind of target is build from a list of sources.

There are several methods to do the same thing.  To avoid confusing the
user with too many choices, I think that we should stick to the idea
that commands like ":program" and ":dll" are a simple way for selecting
_what_ kind of target in to be build from a list of sources.  If you
want to change _how_ the building is done attributes and variables are
used.

The _how_ and _what_ are a bit exchangable.  You could say a shared
library and a static library and both libraries that are build in a
different way.  Or you could say that they are different things.  But
since the differences are more than the command used for building (the
object files are different), I would say they are really different
things.  You also use the results in a different way.

For something build with libtool it's just the build command that
differs, thus I would call that _how_ building is done.

> That would also open up a route to
> 
> :lib blurfl { filetype=libtoollibrary } : blurfl.c
> 
> Which is what I'm going to want in the end, as well. The final step of all 
> three of these could be implemented as buildlib actions with different 
> filetypes, just like with programs.

So we have the separation into (1) program (2) static-lib (3) shared-lib
first, and then the build methods (a) normal link (b) use libtool.  Thus
we have six combinations.

Instead of using three different filetypes to tell Aap to use libtool
(libtoolexe, libtoollib, libtooldll), wouldn't it be simpler to use a
{uselibtool} attribute?  Or set the $LTLIBS variable, as suggested in
another message.

> .. but ..
> 
> Now there's the problem of the objects being built for those
> libraries. For static libs, .o is fine. For dynamic libs, AAP uses
> .sho, and those are real object files. For libtool libs, .lo is the
> "object", but it's really a text file describing the object (and the
> real .o files are hidden in $BDIR/.libs/).

For producing libtool libs we could add a command, something like:

	:libtoollib mylib : source.c

That would produce the libtool lib mylib.lo from source.c.

But when you see something like:

	:program myprog {uselibtool} : source.c

This doesn't mean that we compile source.c into source.lo, right?  Thus
using .lo is quite different from using .o and .sho.

Hmm, perhaps another method to tell Aap to use libtool would then be:

	:program myprog : source.c mylib.lo

Does that make sense?  It's like changing the linker when one of the
sources is a C++ source file.

> I can't tell where the object names are created; I suspect
> aap_program() does some magic based on its type parameter.

Yes, and it also depends on the system/compiler.  For some systems the
objects for a shared library are different from normal object files, for
other systems they are equal.


> Now, instead of using that type parameter, we could use the filetype
> parameter to determine the type and extension of object files. For the
> default types - lib, dll, libtoollibrary - those would be built-in.

Note that it's possible that a source file might be used both for
building a static and a shared library.  Thus it might result in both
source.o and source.sho object files.  Thus it's not just a matter of a
different filetype, both files may exist and require a different name.

> For other types, I imagine an extension to :filetype could be used to
> specify information about sources, and this information would be used
> by :lib (and :program).
> 
> For instance:
> 
> :filetypeinfo libtoollibrary
> 	objecttype	libtoolobject
> 	objectext		.lo
> 
> :filetypeinfo dll
> 	objecttype	sho
> 	objectext		.sho
> 
> :filetypeinfo exe
> 	objecttype	object
> 	objectext		.o
> 
> Then whatever weird compilation system (sources to some final product) can be 
> added to aap as follows:
> 
> 0) choose a filetype for the final product (say myproduct)
> 0') choose a filetype for the sources (say mysource)
> 1) define the filetypeinfo information for "myproduct", stating the types of 
> objects used to build the final system and their extensions (say myobjtype 
> and myobj)
> 2) define a compile rule from "mysource" to "myobjtype"
> 3) define a build rule from "myobjtype" to "myproduct"
> 3') define a buildlib rule from "myobjtype" to "myproduct"
> 
> which of 3 or 3' you choose depends on whether you intend your filetype to be 
> used in :lib or in :program contexts. 

This is more or less how it works for :program, :lib and :dll.  It seems
you are trying to make a generic mechanism for this.  Did you read the
documentation for :totype?  (I know, it's not explained very well
yet, fixing that is in the todo list.)

It seems the mechanism you are proposing is taking it one step further.
Let's see if this is really simpler than doing it just with ":totype":

	# define the list of source files
	Sources = source1.c sourc2.y

	# The suffix to be used for our "mo" object files.
	MOSUF = .mo

	# How to build the "mything" program from "mo" object files.
	mything : `src2obj(Sources, sufname = "MOSUF")`
		:do mythingy $source

	# Turn the sources into "mo" object files.
	:totype motype {suffix = $MOSUF} : $Sources

> An alternative, less ambitious approach would be to allow additional { 
> useobjecttype } and { useobjectsuffix } attributes to the :lib and :program 
> target, and use those instead of the additional :filetypeinfo. Then
> 
> :lib bar { filetype=dll } 
> 	{ useobjecttype=sho } 
> 	{ useobjectsuffix=sho } : bar.c
> 
> would be the way to specify a DLL fully like :dll already does.

You are not really building a static library here, thus using ":lib" for
this sounds strange to me.  Instead of doing it this way, or indirectly
with ":filetypeinfo", something like this would be a generic solution:

	:custombuild mybuild theresult
		{objectfiletype = motype} {objectsuffix = .mo}
		: $Sources

":custombuild" is not the best name, but you will get the idea: build a
target in two steps:
	1. Compile each source file into the specified object file type.
	2. Build all the object files together into the target.

For the first step we need to know the object file type and the suffix
used for it ("motype" and ".mo" in the example.  For the second step we
need to know what action to use for building ("mybuild" in the
example).

The equivalent of using ":dll" would be:

	:custombuild builddll mylib {objectfiletype = dllobject}
			{objectsuffix = .sho} : $Sources

In any case you need to define the actions and routes for turning a
source file into a "motype" file, and the action for combining them into
the final result.  That needs to be done only once and can be re-used
for all your projects with "motype" files.


> Dern, now I really need to try to learn Python to implement some of this 
> stuff.
> 
> .. because ..
> 
> it'd be nice to be able to handle fake sources (earlier message) in a nice 
> way, too. The sources of my application might not all be amenable to a simple 
> translation from source name to object name. I'm thinking in particular of 
> being able to put the KDE standard .skel and .stub files - fake sources - in 
> the list, and having AAP automatically translate foo.skel into foo_skel.cc 
> (as a source). What about
> 
> :filetype skel skel
> :filetypeinfo skel
> 	rewriteobjectname %.% %_skel.%
> 
> or perhaps
> 
> 	rewritesourcename %.skel %_skel.cc

I'm trying to avoid a new syntax for things like that.  Python offers
all the expression stuff we need, it's not a good idea to reinvent this.
For the difficult stuff we can add convenience functions, such as
sufreplace().

> This would mean that whenever a file of filetype skel appears as a
> source file and its name is of the form bla.skel, rewrite it to
> bla_skel.cc before doing any objecttype and objectsuffix replacements
> on it. If foo.c { filetype=skel } appears as a source, the rewrite
> rule doesn't match, and no rewriting is done (other than the
> objectsuffix rewrite).

The idea of :program is that you specify the list of ultimate source
files, not some generated file.  Then use the :route command to specify
how to turn your ultimate source file into an object file.  For the
above example:

	:program myprog : source.c foo.skel

	:route skel cpp object
		skel2cpp `sufreplace("", "", source)`_skel.cc
		compile

-- 
Far back in the mists of ancient time, in the great and glorious days of the
former Galactic Empire, life was wild, rich and largely tax free.
Mighty starships plied their way between exotic suns, seeking adventure and
reward among the furthest reaches of Galactic space.  In those days, spirits
were brave, the stakes were high, men were real men, women were real women
and small furry creatures from Alpha Centauri were real small furry creatures
from Alpha Centauri.  And all dared to brave unknown terrors, to do mighty
deeds, to boldly split infinitives that no man had split before -- and thus
was the Empire forged.
		-- Douglas Adams, "The Hitchhiker's Guide to the Galaxy"

 /// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net   \\\
///          Creator of Vim - Vi IMproved -- http://www.Vim.org          \\\
\\\              Project leader for A-A-P -- http://www.A-A-P.org        ///
 \\\  Help AIDS victims, buy here: http://ICCF-Holland.org/click1.html  ///