On Wed, 12 May 2004, 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. ;-)
You might want to review the patch I submitted about a year and a half ago
-- it's # 18319, and it included some (but certainly not all) of your good
ideas.
In particular, I was careful to distinguish among three separate
functions:
Compiler: Used to turn .c files into .o files.
Linker: Used to combine .o files (and libraries) into an
executable.
Shared Library Builder: Tool to turn .o files into a shared
library. I called it by the Configure variable 'ld',
but better names are certainly welcome.
Each one of these tools needs its own set of flags.
I gather parrot's now trying to include stuff compiled with C++, so you'll
also need a macro for that. Furhter, if parrot's going to include stuff
compiled with C++, the "Linker" will have to be a command that correctly
handles C and C++. On Unix systems, that's probably just the C++
compiler. I don't know what it is on Windows or VMS.
Regarding C++ flags, I'd hope that the C++ compiler would accept the same
flags as the C compiler, but you ought to allow for the possibility of
setting extra c++ -specific flags, so you'll need a macro for that too.
> - 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
> xxx_STATIC_USE cflags and ldflags to use static parrot
> PARROT_STATIC_NAME full, platform dependent name of static parrot lib
> 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
> The name of the parrot library should blend into the current system (and
> might even be different for debug builds, eg libparrot_g.so (is that
> correct?) or parrotd.lib).
For perl5, the direction we went with this issue was to embed the
different build information into the directory, rather than into the
library name. That way, you don't have to change all the command lines
that might link to parrot from -lparrot to -lparrot_g or -lparrot_64 or
-lparrot_mt or -lparrot_longdouble or -lparrot_whatever. Keeping multiple
versions of a parrot shared library on a system at the same time is
tricky, and needs to be very carefully thought out.
--
Andy Dougherty [EMAIL PROTECTED]
