Compiling sguil-server on Release 9.2 i386

Paul Schmehl pschmehl_lists at
Mon Oct 21 16:17:05 UTC 2013

--On October 21, 2013 7:48:59 AM +0200 John Marino 
< at> 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
>> 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 

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

More information about the freebsd-ports mailing list