Date: Mon, 21 Oct 2013 11:15:25 -0500 From: Paul Schmehl <pschmehl_lists@tx.rr.com> To: marino@freebsd.org, 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: <F12E234EE897AD18809D39E4@localhost> In-Reply-To: <5264C04B.2030006@marino.st> 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> <5264C04B.2030006@marino.st>
next in thread | previous in thread | raw e-mail | index | archive | help
--On October 21, 2013 7:48:59 AM +0200 John Marino
<freebsd.contact@marino.st> wrote:
> 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.
>
I discovered this on my own while working on the port this morning.
>
>>> 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.
>
The dependency is mysqltcl. That port installs two files in
${LOCALBASE}/lib/mysqltcl-${PORTVERSION}/. How do you reference those
files without using the portversion?
>>
>>> 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.
>
When I work on my ports I create a new directory ${PORTNAME}-update. Then
I svn the port into that directory, which creates a subdirectory named
${PORTNAME}. With ${.CURDIR}../../../ the build will not descend to
/usr/ports but to /usr/ports/security and the build will break. I fail to
see how that can be correct. If I build ports anywhere other than the
default location, the build will break.
Is this information documented somewhere? And how do I overcome this
obvious problem?
>>
>>> 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?
>
There are multiple ways to point out problems. One way is to point to the
problem and say, "Look - you screwed up here." That's your way, and I can
assure you it doesn't lend to a sense of cooperation and learning.
> You know, you could have just said, "Thank you" as I've spent a
> considerable time on this topic when nobody else did.
>
Yes, and you could have been a lot more pleasant. Don't forget, port
maintainers are volunteers. I spend my personal time working on these
problems, and the thanks I get from you is, hey, you screwed this up, you
screwed that up, in fact, I can see five or six problems just from a brief
look at your port instead of here's what the problem is, and here's a way
to fix it.
It's not an attitude that makes me want to get to work on fixing the
problems.
--
Paul Schmehl, Senior Infosec Analyst
As if it wasn't already obvious, my opinions
are my own and not those of my employer.
*******************************************
"It is as useless to argue with those who have
renounced the use of reason as to administer
medication to the dead." Thomas Jefferson
"There are some ideas so wrong that only a very
intelligent person could believe in them." George Orwell
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F12E234EE897AD18809D39E4>