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
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 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: 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
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
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
> 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 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
serpentine port forces dependency on muine
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="" This may not be the best way as it overloads the MUINE variable differently than it is now overloaded, but it looks like it is logically correct. The obvious alternative is to add: .if defined(MUINE) WITH_MUINE= yes .endif -- 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"