On May 12, 2004, at 1:26 PM, Ron Blaschke wrote:
I have finally sorted out the details of the flags stuff, which I will
present below. Any comments are highly appreciated. Be warned: I am going
to implements this if there are no objections. ;-)
- Targets "shared" and "static" are provided, to build a shared or static
parrot library.
- The following macros will be provided in the Makefile CFLAGS_COMMON common compiler flags LDFLAGS_COMMON common linker flags xxx_STATIC_BUILD cflags and ldflags to build static parrot
We should make it clear that we are talking about building a static lib (to distinguish from what the next macro is intended for)--so how about:
xxx_STATIC_LIB_BUILD or xxx_LIB_STATIC_BUILD
(I'm worried that xxx_STATIC_BUILD by itself isn't clear.)
xxx_STATIC_USE cflags and ldflags to use static parrot
How about:
xxx_STATIC_LINK
PARROT_STATIC_NAME full, platform dependent name of static parrot lib
How about:
LIBPARROT_STATIC
(That's "LIB" to make it clear that this is the lib and not the executable-linked-statically, and "name" is kind of implied.)
xxx_DYNAMIC_BUILD cflags and ldflags to build shared parrot xxx_DYNAMIC_USE cflags and ldflags to use shared parrot PARROT_DYNAMIC_NAME full, platform dependent name of dynamic parrot lib
As above.
LDFLAGS_DYNAMIC_USE should contain "-lparrot" or "parrot.lib", or whatever
necessary, so no need to use PARROT_xxx_NAME to specify linkage
"USE" seems odd to me, though I don't right of have an alternative which is clear.
- When building / using a shared parrot the compiler macro PARROT_LIB_DYNAMIC will be defined, for static PARROT_LIB_STATIC
What will these be used for? Traditionally, there aren't compile-time difference when building a static v. dynamic library, I believe. Maybe this is not the case for Windows?
- When building parrot the compiler macro PARROT_LIB_EXPORTS will be defined, when using parrot PARROT_LIB_IMPORTS
Again, for what use?
I'm not against these last 2 sets of macros--just wondering what the intended use is.
- Symbols that should be exported are declared as
PARROT_API some_function
The include files will be grepped for them, and stored in a file xxx_api
(even on platforms that don't need it). It will look something like this:
Alternatively, we could just parse embed.h -- all and only symbols defined there should be exported. (I believe that's the plan.)
JEff
