One could also take a look at tools/dev/nm.pl, something I submitted to
Leo a few days back. Basically, it tries to be a portable nm frontend.
nm.pl -g -o libparrot.a does more or less the same what you did.
At 12:11 PM -0500 3/14/04, Mitchell N Charity wrote:
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
Marcus Holland-Moritz <[EMAIL PROTECTED]> wrote:
> One of my modules embeds the ucpp preprocessor, which has a
> function init_tables(). The same function exists in parrot.
Renamed.
Anothe
On Mar 15, 2004, at 9:22 AM, Arthur Bergman wrote:
On 15 Mar 2004, at 17:20, Jeff Clites wrote:
We should be able to get the linker to only expose our external entry
points from libparrot. That way, we don't have to worry about the
naming of API which isn't supposed to be called from outside. (
er than relying on a prefix.)
>
> JEff
And how would this be done across platforms, if this works I am happy
with it, but I don't know how.
Arthur
We could always use a source preprocessor to add a uN1qUePr1VaTe_ prefix
to a list of unprefixed global symbols... ;)
Mitchell
(not e
On 15 Mar 2004, at 17:20, Jeff Clites wrote:
On Mar 15, 2004, at 7:36 AM, Leopold Toetsch wrote:
Arthur Bergman <[EMAIL PROTECTED]> wrote:
PDB is too generic ParrotDB_
Of course, "ParrotDB" sounds like "Parrot database"
May be its best if someone who has commit privs just changes the
globa
On Mar 15, 2004, at 7:36 AM, Leopold Toetsch wrote:
Arthur Bergman <[EMAIL PROTECTED]> wrote:
PDB is too generic ParrotDB_
Of course, "ParrotDB" sounds like "Parrot database"
May be its best if someone who has commit privs just changes the
globals
and puts it in - its of not much help to se
Arthur Bergman <[EMAIL PROTECTED]> wrote:
> PDB is too generic ParrotDB_
>> - PF_ PackFile
> ParrotPF , PF alone is already a taken prefix for Packet Filter if I
> don't recall wrong, not to mention the ancient define of PF_
>> - PackFile_ PackFile
> PackFile_ is too generic IMO too, and
On 15 Mar 2004, at 12:54, Leopold Toetsch wrote:
I think all parrot externally visible macros, types and all functions
should be prefixed Parrot_ as a start.
Are patches welcome that change this?
Sure. But we should allow some already used prefixes too, beside
Parrot_.
We have:
Cool, I still th
Arthur Bergman <[EMAIL PROTECTED]> wrote:
> I think all parrot externally visible macros, types and all functions
> should be prefixed Parrot_ as a start.
> Are patches welcome that change this?
Sure. But we should allow some already used prefixes too, beside Parrot_.
We have:
- Parrot_ API
-
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Mitchell N Charity) wrote:
> Leopold Toetsch <[EMAIL PROTECTED]> wrote:
>
>Marcus Holland-Moritz <[EMAIL PROTECTED]> wrote:
>
>> One of my modules embeds the ucpp preprocessor, which has a
>> function init_tables(). The same functio
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
Marcus Holland-Moritz <[EMAIL PROTECTED]> wrote:
> One of my modules embeds the ucpp preprocessor, which has a
> function init_tables(). The same function exists in parrot.
Renamed.
Another item for the embedding/extending todo list: namesp
11 matches
Mail list logo
