Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
Message from discussion PARROT_API, compiler and linker flags (was TODO: Linker magic step for configure)
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Ron Blaschke  
View profile  
 More options May 12 2004, 4:26 pm
Newsgroups: perl.perl6.internals
From: r...@rblasch.org (Ron Blaschke)
Date: Wed, 12 May 2004 22:26:49 +0200
Local: Wed, May 12 2004 4:26 pm
Subject: PARROT_API, compiler and linker flags (was TODO: Linker magic step for configure)
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
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

LDFLAGS_DYNAMIC_USE should contain "-lparrot" or "parrot.lib", or whatever
necessary, so no need to use PARROT_xxx_NAME to specify linkage

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).

- When building / using a shared parrot the compiler macro
PARROT_LIB_DYNAMIC will be defined, for static PARROT_LIB_STATIC

- When building parrot the compiler macro PARROT_LIB_EXPORTS will be
defined, when using parrot PARROT_LIB_IMPORTS

- 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:
----
# Do not edit this file!
# It is generated automatically by xxx

Parrot_new
Parrot_init
----
This file may be processed and used for linker input, to export only the
symbols mentioned.  But this is platform dependent.

The definition of PARROT_API is also platform dependent (I've already
presented it for win32-generic-cl), and should go into api.h.

- The platform names are normalized to
<OS>-<architecture>-<compiler>.  Hmm, should the architecture go first?
(cf PLATFORMS)
Examples are:
linux-ppc-gcc3.2.3
cygwin-x86-gcc3.3.3
win32-x86-cl13.10.3077

Platform specifics will be stored in
config/gen/platform/
  generic/generic/generic  any OS, any architecture, any compiler
  win32/x86/generic        win32, x86, any compiler
  win32/generic/cl         win32, any, MS compiler
  win32/x86/cl             win32, x86, MS compiler
  linux/ppc/gcc            linux, PPC, GCC
  ...
Possible would even be a future extension like:
  win32/x86/cl13.10        win32, x86, MS compiler version > 13.10

Ron


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.