Op Tue, 18 Jul 2006, schreef Jonas Maebe:
> You need something more than merely the remapping of library names.
As I said, you can remap unit names. At some point the user will have to
decide to which one he wants to link, doing it by a unit name remap looks
an elegant solution to me.
> > > I think all this "competing with C" and not-invented-here syndrome is
> > > downright silly, along with all the claiming that most bad things
> > > come from C.
> >
> > That was Almindor not me.
>
> I was replying to a mail from Daniel.
Doesn't matter: Marco was pointing out that all the (bandaid) stuff was
designed for a single toolchain: gcc. We have the opportunity to do better, and
therefore save our users from all kinds of bandaids gcc users need.
If you think supporting gtk-config doesn't hurt the users: If we don't fix
this properly, our users will feel necessary to write this kind of
band-aids for their own libraries as well.
> > and parse it and try to merge it
> > with our own state and support that?
>
> For the external linker not a single bit of internal state merging is
> necessary. It's just a fire-and-forget string. For the internal linker, yes,
> you need some kind of parsing just like you need it for the assembler reader
> and the binary writer (like Daniel mentioned iirc).
I'm quite sure it will at some point be necessary to parse it even for
the external linker, we had our own parsers before we had an internal
assembler.
Daniël
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
