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

[Marco van de Voort]

> Tue, Jul 18, 2006 at 01:22:40AM +0200, Jonas Maebe wrote:
> >libnames when determining how to link, with the default being 1:1.
> 
> I know, but I was trying to point out that e.g. on Mac OS X sometimes  
> you may need
> 
> -lgtk-1.2.0 -lgdk-1.2.0 -lgdk_pixbuf
> 
> and sometimes
> 
> -framework Gtk+-Cocoa
> 
> and sometimes
> 
> -framework Gtk-Carbon

> (and there's a fourth "native" Mac OS X gtk port underway, because  
> the two previous ones were never really finished)
> 
> You need something more than merely the remapping of library names.

I know. We already need more to change libs from static to shared. And I
knew there was more, which I wanted this as formally undocumented
functionality. IIRC I referenced that in the mail to core about the
linkordering.

I'm not entirely happy having put this in parameter form. A keyword based
configuration file is a better way.
 
> >discovery process must be done up front).
> >
> >I want more out of source.
> 
> I don't really care where exactly the information is stored (although  
> the unit somehow seems logical to me, if you want to keep the  
> interface and libs specification together),

Yes and no. The unit should only reference some abstract keyword, and the
mapping to exact actions should happen outside the source. Otherwise
overriding becomes nearly impossible.

Maybe this can be easily introduced by having a second parameter to linklib.
something like 

{$linklib packagename,libraryname} // the comma makes it possible to
keep the old syntax also for migrational purposes.

We can then e.g. easily transform either on libraries or on groups of
libraries ( the packagename above, in the linklib), e.g. to -framework.

This would work for your system too, for the same reasons. If something
fails (e.g. wrong script called, since the new version names it differently,
or some distribution renames it to something-x.y because of a newer version
occupies the "something" name), you'd be able to override simply by
installing a new config file (no new binaries or precompiled sourcetree
needed)

This is also the main reason to make this config a separate file, or a
fpc.cfg #include. Default not for user editing.

So the hoisting out of the source (and too much hardcoding in t_*) should be
separate from if we go -config or manual. The abstract, transformable
representation is needed in either case, also to allow overrides on the
-config usage.

>  but if we change things from the way they are now, then the information
> should be dynamic (i.e., not merely determined at install time, because
> that only shifts the problem) and preferably come from available automatic
> sources (as opposed to the developer having to specify it).

You could simply exit with a hint to run the configuration tool if you
detect that ldconfig has been run. ldconfig is the key here, because to my
limited knowledge it should be run after library changes. 

But IMHO this automatic behaviour is a disaster waiting to happen.
Untransparant, unsupportable, to easily broken, hard to override (it is
easier to let the user make FPC specific config changes, than to have him
edit global pkgconfig and risk breaking his KDE)

But as long as the automated is not the default (which then can be
automatically turned on by IDEs), I don't care, as long as I don't have to
support it.

(Most of the rest of the discussion skipped, only replying to concrete
parts. Viewpoints won't change with more discussion anyway)

> The problem is that it needs to be "refed" every time you compile  
> something using particular units (those depending on libraries  
> requiring this mumbo-jumbo).

(I didn't get this? Surely reading an own config file is quicker than
calling a bunch of external _scripts_ ?)

> >This because I want to be able to say "mail me your compiler state", and
> >send back a new one. Too much automatism will make things less
> >transparant. To the user, but also to the one who has to support it.
> 
> That's what "-al -s" is for.

Too crude. Only the output, not the input. Maybe combined with -va it could
work if enough msgs were emitted with relevant info, but way overkill for
99% of the cases that revolve recognizing variations of a few common
scenario's.
 
(Unix philosophy)
> >_eighties_ Unix philosophy. Have you seen the sheer size of an avg Linux
> >distribution?
> 
> Many small things (and some larger, like OpenOffice.org) together  
> make for large sizes.

I haven't seen small things made in recent years, and previously small
things have grown big.

gcc isn't exactly small, neither is glibc or KDE or Gnome or Eclipse or
Mozilla or Evolution or Samba, or X or anything that the user sees. And
nearly any of them are not run by volunteers anymore either. Nearly all have
fulltimers.

The only stuff that is small are the remnants of the said eighties unix
culture. Tail,wc and friends. The newer branches of that family (perl,
python etc) are all again huge.

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

More fire-and-hope. And you need to parse, otherwise you can't override
except by turning the whole system off and doing everything by hand.