Re: serpentine port forces dependency on muine
On Tue, Aug 25, 2009 at 11:06:18AM -0700, Kevin Oberman wrote:
> I have been trying to remove all dependencies on the broken muine port
> and discovered that an error in the serpentine port Makefile causes
> serpentine to always depend on muine.
>
> The Makefile uses the config option MUINE to indicate whether to build
> the muine plugin, but the script then checks "WITH_MUINE" and always
> build the muine plugin and creates a dependency on muine.
>
> I have opened PR ports/138179.
>
> I patched the Makefile with:
> --- sysutils/serpentine/Makefile.orig 2009-08-25 10:45:24.0 -0700
> +++ sysutils/serpentine/Makefile 2009-08-25 10:07:00.0 -0700
> @@ -29,7 +29,7 @@
>
> .include
>
> -.if (defined(WITH_MUINE) || exists(${LOCALBASE}/bin/muine)) &&
> ${ARCH}=="i386"
> +.if (defined(MUINE) || exists(${LOCALBASE}/bin/muine)) && ${ARCH}=="i386"
> BUILD_DEPENDS+= muine:${PORTSDIR}/audio/muine
> RUN_DEPENDS+=muine:${PORTSDIR}/audio/muine
> PLIST_SUB+= MUINE=""
E...
I strongly doubt that this is the reason for your problems.
Actually, this is exactly how the Ports Collection's "options" framework
is supposed to work: the OPTIONS variable lists just the names of
the options, then bsd.port.mk prompts the user through a dialog
(or just uses the options' default values) and sets either WITH_name
or WITHOUT_name. The port then checks for WITH_name or WITHOUT_name,
just as it does in this case. The option is named "MUINE", but
the bsd.port.mk framework will set "WITH_MUINE" if the user wants it,
or WITHOUT_MUINE if she doesn't (or building in batch mode, since
the option defaults to Off).
So the Makefile check is actually correct.
I find it a little bit hard to believe that it is exactly this change
to the Makefile that helped you get a serpentine build without muine.
Could it be that, in the meantime, you had also removed the muine
port itself? The Makefile check will be satisfied if the MUINE option
is enabled *or* if the "muine" executable is present in /usr/local/bin.
This is most probably because the serpentine configure script looks for
muine itself and uses it unconditionally if it finds it.
So... maybe you just had a /usr/local/bin/muine, and that made
the serpentine port always build with it? Because the Makefile check
is actually correct as per the ports options framework :/
G'luck,
Peter
--
Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
The rest of this sentence is written in Thailand, on
pgps1JG0T34Nn.pgp
Description: PGP signature
Re: serpentine port forces dependency on muine
> Date: Wed, 26 Aug 2009 01:50:01 +0300
> From: Peter Pentchev
>
> On Tue, Aug 25, 2009 at 11:06:18AM -0700, Kevin Oberman wrote:
> > I have been trying to remove all dependencies on the broken muine port
> > and discovered that an error in the serpentine port Makefile causes
> > serpentine to always depend on muine.
> >
> > The Makefile uses the config option MUINE to indicate whether to build
> > the muine plugin, but the script then checks "WITH_MUINE" and always
> > build the muine plugin and creates a dependency on muine.
> >
> > I have opened PR ports/138179.
> >
> > I patched the Makefile with:
> > --- sysutils/serpentine/Makefile.orig 2009-08-25 10:45:24.0
> > -0700
> > +++ sysutils/serpentine/Makefile2009-08-25 10:07:00.0 -0700
> > @@ -29,7 +29,7 @@
> >
> > .include
> >
> > -.if (defined(WITH_MUINE) || exists(${LOCALBASE}/bin/muine)) &&
> > ${ARCH}=="i386"
> > +.if (defined(MUINE) || exists(${LOCALBASE}/bin/muine)) && ${ARCH}=="i386"
> > BUILD_DEPENDS+=muine:${PORTSDIR}/audio/muine
> > RUN_DEPENDS+= muine:${PORTSDIR}/audio/muine
> > PLIST_SUB+=MUINE=""
>
> E...
>
> I strongly doubt that this is the reason for your problems.
>
> Actually, this is exactly how the Ports Collection's "options" framework
> is supposed to work: the OPTIONS variable lists just the names of
> the options, then bsd.port.mk prompts the user through a dialog
> (or just uses the options' default values) and sets either WITH_name
> or WITHOUT_name. The port then checks for WITH_name or WITHOUT_name,
> just as it does in this case. The option is named "MUINE", but
> the bsd.port.mk framework will set "WITH_MUINE" if the user wants it,
> or WITHOUT_MUINE if she doesn't (or building in batch mode, since
> the option defaults to Off).
>
> So the Makefile check is actually correct.
>
> I find it a little bit hard to believe that it is exactly this change
> to the Makefile that helped you get a serpentine build without muine.
> Could it be that, in the meantime, you had also removed the muine
> port itself? The Makefile check will be satisfied if the MUINE option
> is enabled *or* if the "muine" executable is present in /usr/local/bin.
> This is most probably because the serpentine configure script looks for
> muine itself and uses it unconditionally if it finds it.
>
> So... maybe you just had a /usr/local/bin/muine, and that made
> the serpentine port always build with it? Because the Makefile check
> is actually correct as per the ports options framework :/
Ack. You are correct.
If muine found in /usr/local/bin/, it will be built with the plug-in,
regardless of which way the MUINE configure option is set because:
.if (defined(MUINE) || exists(${LOCALBASE}/bin/muine)) && ${ARCH}=="i386"
As a result, you can't deinstall muine as serpentine depends on it, but
you can't build serpentine without a dependency on muine until you
deinstall muine. I am confused as to the whole point of this structure.
If muine is installed, serpentine will be built with the plugin...end of
story. The configuration option does nothing. The only effect it has is
to force the installation of muine on the initial install muine is not
already installed.
I guess the right way is to change the statement to read:
.if defined(MUINE) && ${ARCH}=="i386"
Or, since muine looks to be dead, just rip out the muine stuff.
--
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: ober...@es.net Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: serpentine port forces dependency on muine
On Tue, Aug 25, 2009 at 04:15:51PM -0700, Kevin Oberman wrote:
> > Date: Wed, 26 Aug 2009 01:50:01 +0300
> > From: Peter Pentchev
> >
> > On Tue, Aug 25, 2009 at 11:06:18AM -0700, Kevin Oberman wrote:
> > > I have been trying to remove all dependencies on the broken muine port
> > > and discovered that an error in the serpentine port Makefile causes
> > > serpentine to always depend on muine.
> > >
> > > The Makefile uses the config option MUINE to indicate whether to build
> > > the muine plugin, but the script then checks "WITH_MUINE" and always
> > > build the muine plugin and creates a dependency on muine.
> > >
> > > I have opened PR ports/138179.
> > >
> > > I patched the Makefile with:
> > > --- sysutils/serpentine/Makefile.orig 2009-08-25 10:45:24.0
> > > -0700
> > > +++ sysutils/serpentine/Makefile 2009-08-25 10:07:00.0 -0700
> > > @@ -29,7 +29,7 @@
> > >
> > > .include
> > >
> > > -.if (defined(WITH_MUINE) || exists(${LOCALBASE}/bin/muine)) &&
> > > ${ARCH}=="i386"
> > > +.if (defined(MUINE) || exists(${LOCALBASE}/bin/muine)) && ${ARCH}=="i386"
> > > BUILD_DEPENDS+= muine:${PORTSDIR}/audio/muine
> > > RUN_DEPENDS+=muine:${PORTSDIR}/audio/muine
> > > PLIST_SUB+= MUINE=""
> >
> > E...
> >
> > I strongly doubt that this is the reason for your problems.
> >
> > Actually, this is exactly how the Ports Collection's "options" framework
> > is supposed to work: the OPTIONS variable lists just the names of
> > the options, then bsd.port.mk prompts the user through a dialog
> > (or just uses the options' default values) and sets either WITH_name
> > or WITHOUT_name. The port then checks for WITH_name or WITHOUT_name,
> > just as it does in this case. The option is named "MUINE", but
> > the bsd.port.mk framework will set "WITH_MUINE" if the user wants it,
> > or WITHOUT_MUINE if she doesn't (or building in batch mode, since
> > the option defaults to Off).
> >
> > So the Makefile check is actually correct.
> >
> > I find it a little bit hard to believe that it is exactly this change
> > to the Makefile that helped you get a serpentine build without muine.
> > Could it be that, in the meantime, you had also removed the muine
> > port itself? The Makefile check will be satisfied if the MUINE option
> > is enabled *or* if the "muine" executable is present in /usr/local/bin.
> > This is most probably because the serpentine configure script looks for
> > muine itself and uses it unconditionally if it finds it.
> >
> > So... maybe you just had a /usr/local/bin/muine, and that made
> > the serpentine port always build with it? Because the Makefile check
> > is actually correct as per the ports options framework :/
>
> Ack. You are correct.
>
> If muine found in /usr/local/bin/, it will be built with the plug-in,
> regardless of which way the MUINE configure option is set because:
> .if (defined(MUINE) || exists(${LOCALBASE}/bin/muine)) && ${ARCH}=="i386"
>
> As a result, you can't deinstall muine as serpentine depends on it, but
> you can't build serpentine without a dependency on muine until you
> deinstall muine. I am confused as to the whole point of this structure.
> If muine is installed, serpentine will be built with the plugin...end of
> story. The configuration option does nothing. The only effect it has is
> to force the installation of muine on the initial install muine is not
> already installed.
This structure is probably targeted at the case of the port being built
on a clean system (or at least a clean-ish system). From your
explanations, it seems to me that you are considering the case of
the port being built while a previous version of serpentine is still
installed on the system. While this is, indeed, convenient, and
maybe it is the way it's done by some port building helper tools,
IMHO it's a bit risky: I always prefer to build ports without having
another instance of the port installed to avoid the danger of
the port picking up some of "its own" pieces from the older, currently
installed version. I've had trouble in the past with ftp/curl -
for some reason or other, the test suite sometimes picked up
the libcurl.so from /usr/local/lib/ and not the one it was *supposed*
to use (its own, in its own build directory) - thus the tests for
*newer* features failed. There could be other ways in which this
could pose problems.
Of course, this is merely my humble opinion, and I do realize
the convenience of still having the port installed while you build
its newer version - the old-fashioned way I do things leaves me
X-less and Firefox-less for hours at a time on big upgrades :)
Still, I'm saying this in the hope that you will see the case that
the port maintainer had in mind when writing the Makefile :)
(it's valid for the automated package build systems, too)
> I guess the right way is to change the statement to read:
> .if defined(MUINE) && ${ARCH}=="i386"
"MUINE" is never defined, or at least not by the Ports Options framework.
Re: serpentine port forces dependency on muine
Kevin Oberman wrote:
If muine found in /usr/local/bin/, it will be built with the plug-in,
regardless of which way the MUINE configure option is set because:
.if (defined(MUINE) || exists(${LOCALBASE}/bin/muine)) && ${ARCH}=="i386"
This is incorrect behaviour in any case: ports should not arbitrarily change
configuration depending on what is or is not already installed, and user
choices from OPTIONS dialogues should be paramount. The test should be:
.if defined(WITH_MUINE) && !defined(WITHOUT_MUINE) && ${ARCH} =="i386"
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
Kent, CT11 9PW
signature.asc
Description: OpenPGP digital signature
Re: serpentine port forces dependency on muine
> Date: Wed, 26 Aug 2009 07:05:12 +0100
> From: Matthew Seaman
>
> Kevin Oberman wrote:
>
> > If muine found in /usr/local/bin/, it will be built with the plug-in,
> > regardless of which way the MUINE configure option is set because:
> > .if (defined(MUINE) || exists(${LOCALBASE}/bin/muine)) && ${ARCH}=="i386"
>
> This is incorrect behaviour in any case: ports should not arbitrarily change
> configuration depending on what is or is not already installed, and user
> choices from OPTIONS dialogues should be paramount. The test should be:
>
> .if defined(WITH_MUINE) && !defined(WITHOUT_MUINE) && ${ARCH} =="i386"
The more I look at this port, the stranger it is. It has OPTIONS=, but
does not include bsd.port.options.mk. It then uses tests on a variable
named MUINE (same as the option), not WITH_MUINE or WITHOUT_MUINE.
This effectively makes the "option" not an option, at all. Serpentine
is ALWAYS built with the muine plug-in and, since the muine port is
broken (probably forever), this effectively breaks serpentine.
I am baffled as to how this came to pass. The maintainer (ahze) knows a
lot more about FreeBSD porting than I do, so I have to believe that
there is some sense behind this, but I don't see it.
As serpentine is a part of the gnome2-power-tools metaport and a LOT of
folks are likely to be re-building a lot of ports due to the V8.0
release, I'd really like to see it fixed.
This does not effect me any longer as I have commented out the part of
the configuration that enables the muine plug-in, rebuilt serpentine,
and deinstalled muine, but I am sure it will cause problems for others.
--
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: ober...@es.net Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: serpentine port forces dependency on muine
On Wed, Aug 26, 2009 at 11:47:48AM -0700, Kevin Oberman wrote:
> > Date: Wed, 26 Aug 2009 07:05:12 +0100
> > From: Matthew Seaman
> >
> > Kevin Oberman wrote:
> >
> > > If muine found in /usr/local/bin/, it will be built with the plug-in,
> > > regardless of which way the MUINE configure option is set because:
> > > .if (defined(MUINE) || exists(${LOCALBASE}/bin/muine)) && ${ARCH}=="i386"
> >
> > This is incorrect behaviour in any case: ports should not arbitrarily
> > change configuration depending on what is or is not already installed, and
> > user
> > choices from OPTIONS dialogues should be paramount. The test should be:
> >
> > .if defined(WITH_MUINE) && !defined(WITHOUT_MUINE) && ${ARCH} =="i386"
>
>
> The more I look at this port, the stranger it is.
Uhm, no it isn't, not really :)
> It has OPTIONS=, but does not include bsd.port.options.mk.
It includes bsd.port.pre.mk before testing the option. The part that
takes care of displaying the dialog window to the user is in
bsd.port.pre.mk. This part of the port's Makefile is correct.
> It then uses tests on a variable named MUINE (same as the option),
> not WITH_MUINE or WITHOUT_MUINE.
No it doesn't. The port's Makefile uses tests on WITH_MUINE (line 32).
It then adds a variable named MUINE to the PLIST_SUB - the variable
that contains the substitutions to be made in the pkg-plist file.
And indeed, the pkg-plist file contains a couple of lines with
%%MUINE%% in them - that part works, too, because the port adds
MUINE to PLIST_SUB. This part of the port's Makefile is also correct.
> This effectively makes the "option" not an option, at all. Serpentine
> is ALWAYS built with the muine plug-in and, since the muine port is
> broken (probably forever), this effectively breaks serpentine.
No it isn't. Serpentine is always built with muine *only* if the muine
port is installed on the system at the time serpentine is build, as
I explained in the previous message.
Witness - on my system, where I *don't* have muine installed:
[r...@straylight /usr/ports/sysutils/serpentine]$ sudo make config
(I can't really paste the dialog window, but I now mark the MUINE
option, turning it on)
[r...@straylight /usr/ports/sysutils/serpentine]$ make -V WITH_MUINE
true
[r...@straylight /usr/ports/sysutils/serpentine]$ make -V WITHOUT_MUINE
[r...@straylight /usr/ports/sysutils/serpentine]$ make -V BUILD_DEPENDS |
(fgrep -q muine && echo yep)
yep
[r...@straylight /usr/ports/sysutils/serpentine]$ make -V RUN_DEPENDS | (fgrep
-q muine && echo yep)
yep
[r...@straylight /usr/ports/sysutils/serpentine]$
So, when I selected the Muine option, the port depends on muine in both
its build- and runtime dependencies. Now let's try it the other way...
[r...@straylight /usr/ports/sysutils/serpentine]$ sudo make config
(again, can't paste it, but I unmark the muine option)
[r...@straylight /usr/ports/sysutils/serpentine]$ make -V WITH_MUINE
[r...@straylight /usr/ports/sysutils/serpentine]$ make -V WITHOUT_MUINE
true
[r...@straylight /usr/ports/sysutils/serpentine]$ make -V BUILD_DEPENDS |
(fgrep -q muine && echo yep)
[r...@straylight /usr/ports/sysutils/serpentine]$ make -V RUN_DEPENDS | (fgrep
-q muine && echo yep)
[r...@straylight /usr/ports/sysutils/serpentine]$
So now WITH_MUINE is not defined (but WITHOUT_MUINE is), and thus
the port does NOT have muine in either its build- or runtime dependencies.
> I am baffled as to how this came to pass. The maintainer (ahze) knows a
> lot more about FreeBSD porting than I do, so I have to believe that
> there is some sense behind this, but I don't see it.
There is some sense. As I explained in my previous mail, this will
work just fine if the muine port is not installed on the system at
the time serpentine is built. This is true for the package building
cluster, and it is true for some of us who build our ports this way.
Now... I do agree that having a port change its behavior depending
on what is installed on the system is not really a good idea. It used
to be considered a good idea - I remember a time when many, many ports
did this instead of making the user define lots of variables when
the options framework did not exist yet :) The idea was to make it *easy*
for the user - if she has installed muine, then she most probably *wants*
other apps to support muine, so the serpentine port just goes ahead and
does the right thing without asking. Probably the WITH_MUINE knob was
present even then, before the options framework - and many people
considered this actually comfortable - "Yes, I know I can define this
variable to make serpentine build with muine support, but I don't even
have to do this - I just build muine beforehand and it's all right".
Even then, I was one of the people who didn't like this, and I removed
such autodetection in all the ports I took over, years ago. Still,
other maintainers felt that this was useful and comfortable for the users.
This behavior should have been removed when the OPTI
Re: serpentine port forces dependency on muine
> Date: Thu, 27 Aug 2009 02:10:06 +0300
> From: Peter Pentchev
>
> On Wed, Aug 26, 2009 at 11:47:48AM -0700, Kevin Oberman wrote:
> > > Date: Wed, 26 Aug 2009 07:05:12 +0100
> > > From: Matthew Seaman
> > >
> > > Kevin Oberman wrote:
> > >
> > > > If muine found in /usr/local/bin/, it will be built with the plug-in,
> > > > regardless of which way the MUINE configure option is set because:
> > > > .if (defined(MUINE) || exists(${LOCALBASE}/bin/muine)) &&
> > > > ${ARCH}=="i386"
> > >
> > > This is incorrect behaviour in any case: ports should not arbitrarily
> > > change configuration depending on what is or is not already installed,
> > > and user
> > > choices from OPTIONS dialogues should be paramount. The test should be:
> > >
> > > .if defined(WITH_MUINE) && !defined(WITHOUT_MUINE) && ${ARCH} =="i386"
> >
> >
> > The more I look at this port, the stranger it is.
>
> Uhm, no it isn't, not really :)
>
> > It has OPTIONS=, but does not include bsd.port.options.mk.
>
> It includes bsd.port.pre.mk before testing the option. The part that
> takes care of displaying the dialog window to the user is in
> bsd.port.pre.mk. This part of the port's Makefile is correct.
Whole this may work, it is not recommended by the Porter's
Handbook. (See 5.11.2.2). Still, I suspect it does work as used here.
>
> > It then uses tests on a variable named MUINE (same as the option),
> > not WITH_MUINE or WITHOUT_MUINE.
>
> No it doesn't. The port's Makefile uses tests on WITH_MUINE (line 32).
> It then adds a variable named MUINE to the PLIST_SUB - the variable
> that contains the substitutions to be made in the pkg-plist file.
> And indeed, the pkg-plist file contains a couple of lines with
> %%MUINE%% in them - that part works, too, because the port adds
> MUINE to PLIST_SUB. This part of the port's Makefile is also correct.
Yes, I was wrong about this.
> > This effectively makes the "option" not an option, at all. Serpentine
> > is ALWAYS built with the muine plug-in and, since the muine port is
> > broken (probably forever), this effectively breaks serpentine.
>
> No it isn't. Serpentine is always built with muine *only* if the muine
> port is installed on the system at the time serpentine is build, as
> I explained in the previous message.
>
> Witness - on my system, where I *don't* have muine installed:
Yes, this right, too.
> There is some sense. As I explained in my previous mail, this will
> work just fine if the muine port is not installed on the system at
> the time serpentine is built. This is true for the package building
> cluster, and it is true for some of us who build our ports this way.
>
> Now... I do agree that having a port change its behavior depending
> on what is installed on the system is not really a good idea. It used
> to be considered a good idea - I remember a time when many, many ports
> did this instead of making the user define lots of variables when
> the options framework did not exist yet :) The idea was to make it *easy*
> for the user - if she has installed muine, then she most probably *wants*
> other apps to support muine, so the serpentine port just goes ahead and
> does the right thing without asking. Probably the WITH_MUINE knob was
> present even then, before the options framework - and many people
> considered this actually comfortable - "Yes, I know I can define this
> variable to make serpentine build with muine support, but I don't even
> have to do this - I just build muine beforehand and it's all right".
>
> Even then, I was one of the people who didn't like this, and I removed
> such autodetection in all the ports I took over, years ago. Still,
> other maintainers felt that this was useful and comfortable for the users.
>
> This behavior should have been removed when the OPTIONS variable was
> added to the port - now there *is* an easy way for the user to specify
> whether she wants muine or not. This part I agree with, and I think
> that it should be removed now.
>
> I'm just writing all of this to try to explain the point of view that
> led to this situation in the first place, in revision 1.2 of the
> Makefile, four years ago. At that time, the options framework was
> not completely finished yet, and users still had to specify WITH_*
> and WITHOUT_* variables manually, either on the command line or in
> elaborate config files; thus, the autodetection of muine was, indeed,
> considered by some to be a useful thing. Now, I think it's outgrown
> its usefulness.
OK. I totally mis-read the Makefile and got most of my comments wrong. I
do hope that ahze will "fix" this so that it behaves as people are most
likely to expect it to behave. I will go ahead and update the PR I
submitted on this to simply suggest the removal of the
"|| exists(${LOCALBASE}/bin/muine".
Thanks for you patience in this.
--
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: o
Re: serpentine port forces dependency on muine
On Wed, Aug 26, 2009 at 09:29:10PM -0700, Kevin Oberman wrote:
> > Date: Thu, 27 Aug 2009 02:10:06 +0300
> > From: Peter Pentchev
> >
> > On Wed, Aug 26, 2009 at 11:47:48AM -0700, Kevin Oberman wrote:
> > > > Date: Wed, 26 Aug 2009 07:05:12 +0100
> > > > From: Matthew Seaman
> > > >
> > > > Kevin Oberman wrote:
> > > >
> > > > > If muine found in /usr/local/bin/, it will be built with the plug-in,
> > > > > regardless of which way the MUINE configure option is set because:
> > > > > .if (defined(MUINE) || exists(${LOCALBASE}/bin/muine)) &&
> > > > > ${ARCH}=="i386"
> > > >
> > > > This is incorrect behaviour in any case: ports should not arbitrarily
> > > > change configuration depending on what is or is not already installed,
> > > > and user
> > > > choices from OPTIONS dialogues should be paramount. The test should be:
> > > >
> > > > .if defined(WITH_MUINE) && !defined(WITHOUT_MUINE) && ${ARCH} =="i386"
> > >
> > >
> > > The more I look at this port, the stranger it is.
> >
> > Uhm, no it isn't, not really :)
> >
> > > It has OPTIONS=, but does not include bsd.port.options.mk.
> >
> > It includes bsd.port.pre.mk before testing the option. The part that
> > takes care of displaying the dialog window to the user is in
> > bsd.port.pre.mk. This part of the port's Makefile is correct.
>
> Whole this may work, it is not recommended by the Porter's
> Handbook. (See 5.11.2.2). Still, I suspect it does work as used here.
Errr, this part of the Porter's Handbook only appeared three months
ago, when portmgr@ (Pav Lucistnik in particular, I guess, since it was
he who did most of the work) decided that bsd.port.options.mk was ready
for production use :) Okay, so the serpentine port hasn't been updated
to use options.mk, but there are a lot of other ports that haven't yet
(and yes, I know that some of them are mine ;)
[snip]
> OK. I totally mis-read the Makefile and got most of my comments wrong.
Nah, it's really not that hard to mis-parse a port Makefile - there are
many knobs controlling many aspects of the build, and some of them are
quite alike and can be mistaken for each other. Happens to everyone :)
(and before someone misparses this, I'm *not* criticizing the Ports
Collection - it's great, it just takes some getting used to - continually -
as any more-or-less complex thing in constant development should)
> I do hope that ahze will "fix" this so that it behaves as people are most
> likely to expect it to behave. I will go ahead and update the PR I
> submitted on this to simply suggest the removal of the
> "|| exists(${LOCALBASE}/bin/muine".
>
> Thanks for you patience in this.
No problem, and apologies if my last message has struck you as maybe
a bit confrontational. It was meant as a friendly explanation, and
the reason it started off with a couple of "No, that's not right"
points is that I wasn't thinking too clearly at two in the morning.
Thanks for *your* patience and understanding!
G'luck,
Peter
--
Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
If I were you, who would be reading this sentence?
pgprYcjAFEbum.pgp
Description: PGP signature
