Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 20 Oct 2013 17:47:09 -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:  <424DFFE6C587D7D904EE4B72@Pauls-MacBook-Pro.local>
In-Reply-To: <5263878C.4010206@marino.st>
References:  <3ad43ac4.80255.141d12204c7.Webtop.45@charter.net> <52629946.90204@marino.st> <FF6968EF8FD30D266CF512F5@Pauls-MacBook-Pro.local> <5263878C.4010206@marino.st>

next in thread | previous in thread | raw e-mail | index | archive | help
--On October 20, 2013 9:34:36 AM +0200 John Marino 
<freebsd.contact@marino.st> wrote:

> On 10/20/2013 03:49, Paul Schmehl wrote:
>>>
>>> You should create a PR on sguil-server and document all this there and
>>> request the maintainer fix it properly.  Personally I don't think any
>>> shell commands are needed at all, certainly not to specify a
>>> RUN_DEPENDS.  it's all messed up.
>>>
>>
>> I'm the maintainer, and I can assure you I tested it thoroughly.  The
>> port has built without error on many machines before this came up.  I've
>> personally built and tested it numerous times.
>
> With the MYSQL option set on?  The default is off, so building the
> default configuration numerous times would not have hit this.
>

Yes, of course it was set.  I wouldn't submit a port without testing all 
its options, and committers wouldn't commit a port that doesn't build with 
any options set.

>>
>> Nevertheless, I will take a look at what you've discussed and attempt to
>> determine what the problem is.  It appears that something may have
>> changed in 9.2 that is causing the problem.  Unfortunately I don't have
>> a 9.2 install, so I'll have to set one up before I can test it.
>
> 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.

> 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.

> 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}).

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.

> 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.

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.

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?424DFFE6C587D7D904EE4B72>