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

[Daniël Mantione]

Op Mon, 17 Jul 2006, schreef Jonas Maebe:

> 
> On 17 Jul 2006, at 14:57, Daniël Mantione wrote:
> 
> > > But if the new version has additional (or different) dependencies or
> > > library
> > > names, everything will remain fine with the script (as e.g. with the
> > > FreeBSD
> > > problem which started this discussion).
> > 
> > That is exactly what Marco's code solves, in a generic way. Solving it by
> > parsing gtk-config, tclConfig.sh, and so on is a work that never
> > finishes.
> 
> 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.

Also, fact is we do have an internal linker and it will hopefully be 
used for most platforms in the future. 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.

> The whole point of the *config scripts it that you do not have to care about
> such implementation details at all.

> > > It's the same with different
> > > implementations which maybe be ABI- and API-compatible, but have
> > > different
> > > dependencies.
> > 
> > Solve it using Pascal:
> > 
> > {$ifdef platform}
> > uses library;
> > {$endif}
> > 
> > .... and the compiler will sort out the rest.
> 
> As explained above, a single platform may have multiple implementations
> available. You can of course generate three versions of all gtk units for Mac
> OS X (or even four by now), but that's not really nice either.

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 you can require the user to manually specify everything in
> > > his
> > > config file or on the command line, but it's nicer if this can be
> > > avoided.
> > 
> > If there was a generic way determining library locations: yes
> > gtk-config can only be used to determine the location of one
> > library: libgtk. It is useless for libtcl, for example.
> 
> 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.

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

Daniël