Compiling sguil-server on Release 9.2 i386

[Paul Schmehl]

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