On Mon, Jul 17, 2006 at 01:57:01PM +0200, Jonas Maebe wrote: > >That's not the point. The point is that I consider a solution, that > >tries to > >collect this data automatically, worse than the current situation. > > 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? 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? _and_ at the same time have to maintain the backup too? > >IOW I consider this cure to be worse (more likely to break a release > >systematically and harder to support due to a lack of transparancy > >to end > >users) than the problem, > > I cannot see how this is more likely to break a release > systematically. And it's only as intransparent as we make it (e.g., > apart from the "compiling", "assembling" and "linking", there could > just as well be a "Determining needed libraries using gtk-config..." > message) > > >specially since now we don't have to recompile FPC > >anymore for a lib change. > > 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 _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
