automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

auto generate -DLIBfoo_COMPILATION for libtool libraries


From: Robert Collins
Subject: auto generate -DLIBfoo_COMPILATION for libtool libraries
Date: Wed, 6 Jun 2001 02:43:32 +1000

The attached patch auto defines -DLIBfoo_COMPILATION in the _CFLAGS
variable for libtool libraries.

This is a proof of concept patch only, it's probably the wrong way to do
it, there may be issues with always adding the define even if there are
userland defines present. Consider this a request-to-discuss :]


Idea and reasoning:
on win32 platforms when building dll's, several things have to happen.

a) each separate source file in library as it's compiled needs it's own
list of exports. (note that is _library_ dependant, not source file).
b) each source file for anything that links to that library needs a list
of imports from the library.

Libtool defines -DDLL_EXPORT to hint to a source file when it's being
built that it's being built as a .dll, not as a unix library or a static
win32 library. This isn't enough to produce reliable compilation as a
trivial example can show:

hello.dll
  has one function int hello (const char *who);
  depends on greet.dll

and hello() prints the value of greet from greet.dll

greet.dll
  has one export const char *greet;

Now the header file for greet.h, included when greet.dll is being built,
AND when hello.dll is being built, will generate a __declspec(dllexport)
if the only hint that is given is that a dll is being built - which one?

There is a second define needed to control building source that will be
linking to the dll - commonly LIBfoo_DLL_IMPORT. It is possible to play
precedence tricks with the two defines - check for an IMPORT before a
general DLL_EXPORT. The problem that arises is if a single source file
is used to define variables in more than one .dll - say a common header
for several libraries, that includes each sub library.

However: one very clear solution I've seen before, and the current
libtool '/demo' package uses is to define LIBfoo_COMPILATION.

The problem then, is that libtool doesn't know what source files are
being built for what library. _AND_ it doesn't know if the same source
.c|.cpp file turns up in more than one library.

Automake knows this however, so I've added a rule to the automake
libtool code to define the LIBfoo_COMPILATION define for every source
file being built for a given library.

Why not let the user do it? Well, why doesn't the user define DLL_EXPORT
? If it's a reasonable solution, and it should apply broadly, the
infrastructure should do it.

Why _always_ add it? (ie why add to the user CFLAGS? )

because in the example above libhello_la_CFLAGS needs to end up
-DLIBHELLO_COMPILATION -DLIBGREET_DLL_IMPORT

so the user can just set
libhello_la_CFLAGS = -DLIBGREET_DLL_IMPORT

and know it'll turn out alright.

Comments/feedback/laughter are welcome.

BTW: I'm not a perl progammer. It shows. If the concept is good feel
free to tidy up and put it inn.

Rob

Attachment: autodefineLIBFOO_COMPILATION.patch
Description: Binary data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]