From owner-freebsd-ports@FreeBSD.ORG Mon Oct 21 05:49:32 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DC413BFA for ; Mon, 21 Oct 2013 05:49:32 +0000 (UTC) (envelope-from freebsd.contact@marino.st) Received: from shepard.synsport.net (mail.synsport.com [208.69.230.148]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B3E542B9C for ; Mon, 21 Oct 2013 05:49:32 +0000 (UTC) Received: from [192.168.0.22] (unknown [130.255.26.50]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by shepard.synsport.net (Postfix) with ESMTP id F3C4143600; Mon, 21 Oct 2013 00:49:15 -0500 (CDT) Message-ID: <5264C04B.2030006@marino.st> Date: Mon, 21 Oct 2013 07:48:59 +0200 From: John Marino User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Paul Schmehl Subject: Re: Compiling sguil-server on Release 9.2 i386 References: <3ad43ac4.80255.141d12204c7.Webtop.45@charter.net> <52629946.90204@marino.st> <5263878C.4010206@marino.st> <424DFFE6C587D7D904EE4B72@Pauls-MacBook-Pro.local> In-Reply-To: <424DFFE6C587D7D904EE4B72@Pauls-MacBook-Pro.local> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: s_gammons@charter.net, freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: marino@freebsd.org List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 05:49:32 -0000 On 10/21/2013 00:47, Paul Schmehl wrote: > --On October 20, 2013 9:34:36 AM +0200 John Marino >> It is not a mystery what is wrong. >> The RUN_DEPENDS is being executed as a shell command, not a make >> definition. > > You're wrong. The RUN_DEPENDS does not have a shell command embedded in > it anywhere. When you indent, it executes the command in the shell. Notice that only make targets are indented. >> That was never correct, and the new bmake makes this much >> more obvious. Secondly, I'm pretty sure you can specify >> databases/mysqltcl without having to execute a make command on that >> port. > > You're pretty sure? Rather than hard code a version, which would break > the port the moment mysqltcl was updated, I chose to use the existing > port version, which would work no matter what version was current on any > particular box. Yes, I am sure. You can tell it that the port is the dependency regardless of version. If you absolutely wanted to specify a file, you can specify a different one that the file name doesn't change. Yes, you can a RUN_DEPENDS without that line in ways that are robust. > >> Thirdly, you use ${MYSQLTCL_VER}, but it's never defined. > > Yes, and that is a problem. I noticed that last night when I was > looking at the port. Line 46 should read MYSQLTCL_VER= @${ECHO_CMD} > $$(${MYSQLTCL_CMDS}). Again, completely unnecessary. Specify the *NON-INDENTED* RUN_DEPENDS in a better way. > > It looks like that port has changed, however, because it no longer > appends the version number to the name of the port, so I can probably > drop that entirely. I won't know until I test it. > >> Apparently line 46 was intended to define it but does not. Lastly, if >> you were to use a shell command (which I highly discourage), it should >> be something like this (not indented, and definitely not hardcoded to >> ${PORTSDIR}): >> MYSQLT_VER!= cd ${.CURDIR}/../../databases/mysqltcl && ${MAKE} -V >> PORTVERSION >> > > What do you suggest it be hardcoded to? ${PORTSDIR} can be set to > anything on an individual system. Using your construction forces it to > be in /usr/ports. Although that's the default, it's by no means > guaranteed that the ports tree will exist there on any given system. > That's why we use macros in Makefiles - to avoid forcing users to stick > to the default structure. I just showed you. Replace ${PORTSDIR} with ${.CURDIR}/../../ I know you haven't believed a thing I've said so far, but using ${PORTSDIR} can break the build in specific configurations. And yes, we've been replacing it with .CURDIR in other ports. > >> So that's like 4 or 5 errors right off the bat, problems that were >> always present. I suspect the legacy make simply didn't define >> RUN_DEPENDS and continued building, so mysqltcl was never specified in >> the package. >> > > Because MYSQLTCL_VER is never defined, I think the RUN_DEPENDS should > fail. It didn't. I can't explain why. (I've slept since I last worked > on that port.) I can assure you I tested the port with the option > enabled and it built and ran fine. So you state previously that it *HAD* to be defined for RUN_DEPENDS to work, and now state that it wasn't defined but RUN_DEPENDS did work? Doubtful and easily verifiable. Find an old platform where it "worked" and type "make -V RUN_DEPENDS" and see if mysqltcl is in the list. I believe it simply wasn't defined which didn't prevent this build from building (it was indented, remember?). I think the error was masked with the previous version of make. > > But I doubt seriously that has anything to do with the error that the OP > reported. It's probably related to the change to bmake, which I will > have to investigate, if I have to continue to define the port version > for mysqltcl. It looks like I might not have to any more. > > I'll also have to update the port to use the new STAGE syntax, so this > will take a little while. > > In the future, I would appreciate it if you adopt a less smug attitude > about somebody else's work. Or take over the port if you think you're > so much better. There's three sguil ports. You're welcome to take over > maintainership if you think you're God's gift to port building. I guess you still feel this way after what I just wrote? What did I do, beside help one of the port's users get going and point out the problems with it and telling the user to write a PR? You know, you could have just said, "Thank you" as I've spent a considerable time on this topic when nobody else did. John