Re: Linking and autoloading of dependent extensions

On 27 May 2014 17:47, "Johannes Schlüter" <johannes@schlueters.de> wrote: > > On Tue, 2014-05-27 at 17:30 +0200, Michael Wallner wrote: > > > Well, ok... so that's absolutely not the problem I'm trying to solve. > > You can still load that stubbornly named extensions manually and > > nothing will complain, even if something has a dependency on it. > > > > > > I'm about e.g. pecl install & going ahead without reordering extension > > entries... > > The issue is this can pull in the wrong extension giving the user a hard > time to understand how and why that happens. Could you give an example? I can hardly imagine a likely scenario... > And I don't think this will solve the "pecl install & going ahead" wish > - what should "pecl install" do? - Add new extensions to the end of the > file? So it will be loaded two times? Wa? pecl will download, build and install the dependencies listed in package.xml. It is smart enough to not add the same extension line twice. Frankly, I'm not sure what you are talking about. > I think the solution is more in the loading and startup logic. I think > we should only load explicitly mentioned extensions (or alternatively Which is the way it currently is, isn't it? > *all* extension in extension dir, while that has issues, too, think i.e. Sounds crazy. Distributions also ship lots of not enabled extensions. > Windows where we distribute a bunch of dlls which require some 3rd party > libs in proper places), then analyze the dependencies, order the startup > call accordingly and start them up. > > (this all won't solve issues where lazy linking doesn't work and we need > system level symbols from other extensions, though ... but I think > systems without working RTLD_LAZY are rare these days) My approach is quite unintrusive, should work in 90% of cases as before, and in 10% improved as intended. (Given I solve the install_root dilemma) Cheers, Mike