> 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. _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel