Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:74530 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 45442 invoked from network); 27 May 2014 16:10:02 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 27 May 2014 16:10:02 -0000 Authentication-Results: pb1.pair.com header.from=mike.php.net@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=mike.php.net@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.41 as permitted sender) X-PHP-List-Original-Sender: mike.php.net@gmail.com X-Host-Fingerprint: 209.85.213.41 mail-yh0-f41.google.com Received: from [209.85.213.41] ([209.85.213.41:39449] helo=mail-yh0-f41.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 6C/C4-18053-8D8B4835 for ; Tue, 27 May 2014 12:10:00 -0400 Received: by mail-yh0-f41.google.com with SMTP id f73so7644356yha.14 for ; Tue, 27 May 2014 09:09:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=dLfeWV9X4Sj1Qj/v4dNDIaeriJAOtwodhGe2Q6UaqfU=; b=ClzZLnIaQJ+uyWRVfVux74rH5tXjMZu783RwTAoVCcGAoT5bdysYC9a+xW3Cyrbwdr wVbe4ceU93YQRc2r4e1nJCiwpRF1WVL24iyWcN1Brt3B4zk4es8pasBN1EuPrRwz4+av NHGM4uDEP0MqQvQrduYc4P4h0TdxNKPziu3JJ41z+zewkesgXL74FOurbhjHX1/kW5A9 LpuN9HI8QLRYQI+yBL18su4cZ4fLVO4dnvcTAY7+bG7tzWlPy6yDxMJ5HbBBpfnaxGoh 12DO2yxLJWxiKqFTVRs4W6W7wKaHP3A7n9ANuaYxtDnewA9cKRl8b+53nj7oClAWRMV+ BvvQ== MIME-Version: 1.0 X-Received: by 10.236.0.200 with SMTP id 48mr48246553yhb.72.1401206996972; Tue, 27 May 2014 09:09:56 -0700 (PDT) Sender: mike.php.net@gmail.com Received: by 10.170.191.69 with HTTP; Tue, 27 May 2014 09:09:56 -0700 (PDT) Received: by 10.170.191.69 with HTTP; Tue, 27 May 2014 09:09:56 -0700 (PDT) In-Reply-To: <1401205632.2998.67.camel@guybrush> References: <1401193927.2998.50.camel@guybrush> <1401200710.2998.56.camel@guybrush> <1401205632.2998.67.camel@guybrush> Date: Tue, 27 May 2014 18:09:56 +0200 X-Google-Sender-Auth: az8Xdy1Ln5hbKbOPCxcu0sjeXRQ Message-ID: To: =?UTF-8?Q?Johannes_Schl=C3=BCter?= Cc: PHP Internals Content-Type: multipart/alternative; boundary=089e0153712e4fba0b04fa63ed76 Subject: Re: [PHP-DEV] Linking and autoloading of dependent extensions From: mike@php.net (Michael Wallner) --089e0153712e4fba0b04fa63ed76 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 27 May 2014 17:47, "Johannes Schl=C3=BCter" wro= te: > > 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 --089e0153712e4fba0b04fa63ed76--