[fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2

[Jonas Maebe]

On 17 Jul 2006, at 16:01, Daniël Mantione wrote:

>> As I said, you do not have to parse that unless you have an  
>> internal linker.
>> And even then you only have to parse linker options for the  
>> platforms you
>> support. Also, depending on which gtk you link against on Mac OS X  
>> you may
>> need to link umpteen gtk/gdk libraries, or need a "-framework Gtk+- 
>> Cocoa" or
>> similar linker  switch (which would be hard to support with  
>> Marco's approach).
>
> Ok, with gtk-config the right way to get the libraries is "gtk- 
> config --libs".
> With tclConfig.sh you have to source that in a shell script and read
> environment variables afterwards.
>
> So, in order to support this, we would need to write a hack when a
> {$linklink gtk} occurs and write gtk-config specific code. For a  
> different
> library we would need a different hack.

Of course not. You should never change a {$linklib magicstring} into  
some command. The exact command(s) to be executed would have to be  
embedded in the unit with a compiler directive (and probably, just  
like library name, be ifdef'd per platform).

> Also, fact is we do have an internal linker and it will hopefully be
> used for most platforms in the future.

I do not see this happening any time soon for e.g. Mac OS X.

> Ultimately it will go in the same
> direction as with the assembler readers even for external linkers: In
> order to fully understand the parameters, the compiler must understand
> them.

Yes, this is a downside of integrating everything (with the upside  
being speed and memory usage, obviously).

> Generate 3 units, and introduce some unit aliases for gtk like  
> Marco did
> for libraries, problem solved. That is still a lot more generic  
> ‹solution
> than *-config and a lot less work.

Of course making the developer type in everything manually is always  
more generic and less work for us. That is not my point, and I'm not  
against providing this functionality. As I said in my reply to Marco,  
I consider it complementary, as a last resort if all else fails.

>> It's not just gtk which uses this, at east sdl also does. And the  
>> fact that it
>> doesn't solve world hunger does not mean it's not useful to  
>> support it.
>
> We should design a system that does solve world hunger. I'm serious  
> about
> that: if we want to be a more professional tool than C, we should  
> not copy
> the defficiencies. Makefiles are one of them, Autohell is another, and
> I consider this one such a thing as well.

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. If anything, it comes mostly from the standard Unix  
design philosophy (small, well-delineated tools which perform their  
core function and *only* that core function). Most *nix C compilers  
follow that principle very well, but other C development environments  
are more integrated (like commercial Mac and Windows IDEs, where you  
sometimes can hardly e.g. tell the compiler from the linker).

We are only a small team, and by playing the elite Pascal geeks who  
are going to show how much the C world sucks by doing everything  
different, we are going to
keep getting stuck by having to reimplement everything because we  
cannot work with what is already there. People often talk about how  
stupid Mac users supposedly are and how elite they consider  
themselves. Well, this Pascal-elitism and C-hostility by some gives  
the Pascal community just as bad a name, even though just like in the  
Mac community most people probably couldn't care less about these  
little superiority wars.

To get back on topic: the more hacks you add to work around already- 
existing infrastructure "because we don't want to rely on external  
tools", the more you force yourself to keep doing that more and more  
forever in the future. If you like that, fine. I don't.

The problem in this particular case is not C, it is the way most OS's  
(do not) support library management. There are various workarounds to  
make it less painful, and this *-config script thing is one way which  
is fairly straightforward and which is being adopted in various  
places (sometimes even fairly general, grouping everything together  
in a global pkg-config script). Adding support for using this  
existing infrastructure is good if it can help solving some problems  
without people needing to know the nitty-gritty details of how the  
libraries are called on their system.

>>> Still, you can put some autodetections in samplecfg, but the  
>>> compiler
>>> itself is really the wrong location to do so.
>>
>> samplecfg only works at install time of the compiler, which is the  
>> wrong time.
>> People don't decide at install time which package, which variant  
>> and which
>> version of it they will want to use one day.
>>
>> The compiler or linker is the only right place to do it (unless  
>> you wrap the
>> whole thing with a configure script and Makefiles, in which case  
>> you can do it
>> there -- but our compiler largely replaces exactly that).
>
> This we agree on, the compiler should do the work.

Above you said that the compiler is the wrong location?

Anyway, I never said I agree with this principle (although it sure is  
very convenient in a lot of cases, in others it's very annoying  
because it requires that you roll your own solution for everything).  
I simply said this is how the compiler works.


Jonas