From owner-freebsd-ports@FreeBSD.ORG Fri Apr 11 18:49:05 2003 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1762A37B401 for ; Fri, 11 Apr 2003 18:49:05 -0700 (PDT) Received: from mail.bellavista.cz (mail.bellavista.cz [213.235.167.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 05E1243F3F for ; Fri, 11 Apr 2003 18:49:04 -0700 (PDT) (envelope-from neuhauser@bellavista.cz) Received: from freepuppy.bellavista.cz (freepuppy.bellavista.cz [10.0.0.10]) by mail.bellavista.cz (Postfix) with ESMTP id EA2BC349 for ; Sat, 12 Apr 2003 03:49:01 +0200 (CEST) Received: by freepuppy.bellavista.cz (Postfix, from userid 1001) id D754B2FDCD9; Sat, 12 Apr 2003 03:49:00 +0200 (CEST) Date: Sat, 12 Apr 2003 03:49:00 +0200 From: Roman Neuhauser To: freebsd-ports Message-ID: <20030412014900.GH36951@freepuppy.bellavista.cz> Mail-Followup-To: freebsd-ports Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.1i Subject: lang/php4, www/mod_php4{Makefile,scripts/configure.php} X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Apr 2003 01:49:05 -0000 dirk@ seems to have disappeared, so I thought I'd think aloud here. It's quite obvious that the decision to retire lang/php4 was shortsighted. But that's not the only problem with PHP(-related) ports IMO. Another sore is that PEAR depends on mod_php4, leading to absurdities like this one: Port: pear-Console_Getopt-1.0 Path: /usr/ports/devel/pear-Console_Getopt Info: PEAR command-line option parser Maint: ports@FreeBSD.org Index: devel www B-deps: apache-1.3.27_4 expat-1.95.6_1 mod_php4-4.3.1 mysql-client-3.23.55 pear-install-4.3.0 R-deps: apache-1.3.27_4 expat-1.95.6_1 mod_php4-4.3.1 mysql-client-3.23.55 pear-install-4.3.0 But I'll save that for later. I thought I'd start with another issue: www/mod_php4/Makefile uses a script to display a dialog to the user, and set ${CONFIGURE_ARGS} and ${LIB_DEPENDS} accordingly. If you want a noninteractive build, you have to do e. g. `make install -DBATCH PHP4_OPTIONS="MySQL mcrypt dBase"`. This is quite different from the usual -DWITH_MYSQL -DWITH_MCRYPT ... way, and so has a non-zero WTF factor. I have an unfinished patch (http://www.innuendo.cz/smradoch/mod_php4-port.diff) that shifts the *_DEPENDS and CONFIGURE_ARGS foot work back to the Makefile, so that the configure.php script puts just WITH_* variables in Makefile.inc. Has such a patch any chance of getting committed? (Note that at least this version has issues: the "Define WITH_APACHE2..." message is printed twice, and I have no idea why... I'm no bsd.port.mk wizard.) If such a change was accepted, I would continue with reviving lang/php4. It would howver make more sense IMO if lang/php4 was the master, and mod_php4 turned into a slave port, similar to www/mod_{perl,python} (which are technically not slaves, they have USE_{PERL,PYTHON}). lang/php4 should install the CLI "SAPI"; there should be a www/php-cgi port. AFAICT, compiling and installing the proper SAPI is just a matter of --enable-cgi / --enable-cli / --with-apxs plus the right ${INSTALL_TARGET}. Do you think this is reasonable? -- If you cc me or remove the list(s) completely I'll most likely ignore your message. see http://www.eyrie.org./~eagle/faqs/questions.html