On 17 Jul 2006, at 14:31, Marco van de Voort wrote:
There's no reason why a default fallback to the current system
couldn't be supported.
If it doesn't exist. But what if it fails?
The current solution also fails from time to time. And there would
switch to disable this gtk-config calling (just like there are
switches to disable assembling and/or linking).
Or if a user pops up in the
maillist with a gtk-config related error? Do you really want to
support
something that you don't control?
Yes, I prefer that unless the existing solution is so bad it fails
almost all the time, or if the alternative is at least as versatile/
compatible and has significant advantages. Most of the messages about
*config failing is that the script isn't found at all by the
configure script, which would be a non-issue for us.
_and_ at the same time have to maintain
the backup too?
The "backup" must be maintained anyway for libraries which do not
come with such a script.
I do not understand this last part. Are you talking about dynamically
loading libraries at run time or so?
No. Simple the alias stuff. See the original msg from me, last part.
To
- change a libname mentioned in a linklib,
- to conditionally add a lib (include lib a if lib b is used, like
the libgcc
during 2.0.4 pkging, though maybe that must be static),
- or to change order of libs,
no FPC repository or fpc binary recompile is necessary anymore
I see this rather as complementary to supporting the *config scripts:
if the *config scripts fail, and if the library names defined in the
units are wrong, then you can still work around it with these options.
Jonas
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
