Date: Mon, 21 Oct 2013 07:48:59 +0200 From: John Marino <freebsd.contact@marino.st> To: Paul Schmehl <pschmehl_lists@tx.rr.com> Cc: s_gammons@charter.net, freebsd-ports@freebsd.org Subject: Re: Compiling sguil-server on Release 9.2 i386 Message-ID: <5264C04B.2030006@marino.st> In-Reply-To: <424DFFE6C587D7D904EE4B72@Pauls-MacBook-Pro.local> References: <3ad43ac4.80255.141d12204c7.Webtop.45@charter.net> <52629946.90204@marino.st> <FF6968EF8FD30D266CF512F5@Pauls-MacBook-Pro.local> <5263878C.4010206@marino.st> <424DFFE6C587D7D904EE4B72@Pauls-MacBook-Pro.local>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
<Sigh>
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5264C04B.2030006>