Re: OPTIONS handling doesn't seem to work fully in dependencies anymore
Alex Dupre wrote:
The attached patch should solve this erratic behavior.
Another quick patch, that removes handling OPTIONS as a special case.
--
Alex Dupre
--- bsd.port.mk.orig2008-09-19 23:15:37.0 +0200
+++ bsd.port.mk 2008-09-19 23:29:30.0 +0200
@@ -3229,17 +3229,6 @@
.endif
-#
-# Do preliminary work to detect if we need to run the config
-# target or not.
-#
-
-.if (!defined(OPTIONS) || defined(CONFIG_DONE) || \
- defined(PACKAGE_BUILDING) || defined(BATCH))
-_OPTIONS_OK=yes
-.endif
-
-
# The following are used to create easy dummy targets for
# disabling some bit of default target behavior you don't want.
# They still check to see if the target exists, and if so don't
@@ -4114,7 +4103,7 @@
_SANITY_SEQ= ${_CHROOT_SEQ} pre-everything check-makefile check-categories \
check-makevars check-desktop-entries
check-depends \
check-deprecated check-vulnerable
buildanyway-message \
- options-message
+ options-message config-conditional
_FETCH_DEP=check-sanity
_FETCH_SEQ=fetch-depends pre-fetch pre-fetch-script \
do-fetch post-fetch post-fetch-script
@@ -4165,12 +4154,8 @@
.for target in extract patch configure build install package
-.if !target(${target}) && defined(_OPTIONS_OK)
+.if !target(${target})
${target}: ${${target:U}_COOKIE}
-.elif !target(${target})
-${target}: config-conditional
- @cd ${.CURDIR} && ${MAKE} CONFIG_DONE=1 ${__softMAKEFLAGS}
${${target:U}_COOKIE}
-.elif target(${target}) && defined(IGNORE)
.endif
.if !exists(${${target:U}_COOKIE})
@@ -5936,7 +5921,7 @@
.if !target(config-conditional)
config-conditional:
-.if defined(OPTIONS)
+.if defined(OPTIONS) && !defined(PACKAGE_BUILDING) && !defined(BATCH)
.if exists(${OPTIONSFILE})
# scan saved options and invalidate them, if the set of options does not match
@. ${OPTIONSFILE}; \
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: OPTIONS handling doesn't seem to work fully in dependencies anymore
John Baldwin wrote: Ahh, I think I see now. It requires one OPTIONS using port to mask the dependencies. Exactly. I thought the same thing, probably yes, but I dunno why it was added in such way from the beginning, so I tried to create the simplest and surely working patch maintaining the current workflow. Ok. Probably it was added in such way because at the beginning there wasn't the config-conditional target and runing the config target for every port (re)build was not a bright idea. If I have time I'll try to make a patch following this rationale, but in the meanwhile my previous patch seems good enough. -- Alex Dupre ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: OPTIONS handling doesn't seem to work fully in dependencies anymore
On Thursday 18 September 2008 03:18:17 pm Alex Dupre wrote: > John Baldwin wrote: > > Trust me, since I rebuild from scratch all the time, I quite remember when > > options were first added and I'd kick off a build of kde or some such > > overnight and check my screen session in the morning only find it hadn't > > build hardly anything b/c it had popped up the option screen for gettext. :) > > Me, too, really :-) But kde3 meta-port doesn't use the OPTIONS > framework, even if it displays the dialog box. And when the OPTIONS > framework was added, very few ports actually used it, so it was very > very rare to incur in *direct* dependencies between two OPTIONS-enabled > ports. The kde4 meta-port now uses it, so it became obvious that > something wasn't working as expected when you tried to build it. Ahh, I think I see now. It requires one OPTIONS using port to mask the dependencies. > > I wonder why it has to be this hackish btw. Could config-conditional simply > > be in the list of targets before 'fetch' or some such? > > I thought the same thing, probably yes, but I dunno why it was added in > such way from the beginning, so I tried to create the simplest and > surely working patch maintaining the current workflow. Ok. -- John Baldwin ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: OPTIONS handling doesn't seem to work fully in dependencies anymore
John Baldwin wrote: Trust me, since I rebuild from scratch all the time, I quite remember when options were first added and I'd kick off a build of kde or some such overnight and check my screen session in the morning only find it hadn't build hardly anything b/c it had popped up the option screen for gettext. :) Me, too, really :-) But kde3 meta-port doesn't use the OPTIONS framework, even if it displays the dialog box. And when the OPTIONS framework was added, very few ports actually used it, so it was very very rare to incur in *direct* dependencies between two OPTIONS-enabled ports. The kde4 meta-port now uses it, so it became obvious that something wasn't working as expected when you tried to build it. I wonder why it has to be this hackish btw. Could config-conditional simply be in the list of targets before 'fetch' or some such? I thought the same thing, probably yes, but I dunno why it was added in such way from the beginning, so I tried to create the simplest and surely working patch maintaining the current workflow. -- Alex Dupre ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: OPTIONS handling doesn't seem to work fully in dependencies anymore
On Thursday 18 September 2008 04:51:11 am Alex Dupre wrote: > John Baldwin ha scritto: > > It used to work. > > I was thinking the same thing, but actually it never worked in that way. Trust me, since I rebuild from scratch all the time, I quite remember when options were first added and I'd kick off a build of kde or some such overnight and check my screen session in the morning only find it hadn't build hardly anything b/c it had popped up the option screen for gettext. :) > > I was just guessing about how it might not be working now > > based on reading the existing logic. I have not delved into the history to > > see what has changed. > > The attached patch should solve this erratic behavior. I wonder why it has to be this hackish btw. Could config-conditional simply be in the list of targets before 'fetch' or some such? -- John Baldwin ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: OPTIONS handling doesn't seem to work fully in dependencies anymore
John Baldwin ha scritto:
It used to work.
I was thinking the same thing, but actually it never worked in that way.
I was just guessing about how it might not be working now
based on reading the existing logic. I have not delved into the history to
see what has changed.
The attached patch should solve this erratic behavior.
--
Alex Dupre
--- bsd.port.mk.orig2008-09-18 10:31:14.0 +0200
+++ bsd.port.mk 2008-09-18 10:46:02.0 +0200
@@ -3234,7 +3234,7 @@
# target or not.
#
-.if (!defined(OPTIONS) || defined(CONFIG_DONE) || \
+.if (!defined(OPTIONS) || defined(CONFIG_DONE_${UNIQUENAME:U}) || \
defined(PACKAGE_BUILDING) || defined(BATCH))
_OPTIONS_OK=yes
.endif
@@ -4169,7 +4169,7 @@
${target}: ${${target:U}_COOKIE}
.elif !target(${target})
${target}: config-conditional
- @cd ${.CURDIR} && ${MAKE} CONFIG_DONE=1 ${__softMAKEFLAGS}
${${target:U}_COOKIE}
+ @cd ${.CURDIR} && ${MAKE} CONFIG_DONE_${UNIQUENAME:U}=1
${__softMAKEFLAGS} ${${target:U}_COOKIE}
.elif target(${target}) && defined(IGNORE)
.endif
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: OPTIONS handling doesn't seem to work fully in dependencies anymore
Alexey Dokuchaev wrote: > I also don't think that we can simply tell our users to user portmaster > or some force-config switches. If you read my post carefully I was suggesting that using portmaster would be a temporary workaround while the actual problem is (hopefully) being fixed. Doug -- This .signature sanitized for your protection ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: OPTIONS handling doesn't seem to work fully in dependencies anymore
On Wednesday 17 September 2008 03:44:14 am Alexey Dokuchaev wrote: > On Wed, Sep 17, 2008 at 08:52:31AM +0200, Alex Dupre wrote: > > Alexey Dokuchaev wrote: > > >Nevertheless, going back to rev. 1.559 of b.p.m. restores correct > > >behavior. > > > > Are you sure? I didn't try, but that commit seems to add new reasons to > > show up the dialog box while not removing any of the old ones. > > Running "make config-recursive" still works (and it calls recursively > > "make config-conditional" that works), so it seems john's analysis is > > correct, but I cannot figure how (and if) ever worked before. > > Perhaps I was too fast in my response; I cannot reproduce it now. While > I'm trying to continuously approach revision that used to work, I'm > starting to suspect that what if it never actually worked? > > John, how old was your ports tree on 6.x? Maybe this can shed some light > on the subject.. I had updated it the day before my e-mail. When I noticed that ports weren't popping up config screens, I actually stopped my build of ports/x11/kde4 at one point and did a 'make config-recursive' from that port and encountered several config screens (libxine, qt4-gui, etc.) -- John Baldwin ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: OPTIONS handling doesn't seem to work fully in dependencies anymore
On Wednesday 17 September 2008 02:41:07 am Alex Dupre wrote: > Doug Barton wrote: > > John was referring to the problem of 'make config' not being called for > > ports being installed as dependencies of a port that has OPTIONS. > > John said (correct me if I'm wrong) that with an up-to-date system > OPTIONS doesn't correctly shows up (when the top port has OPTIONS), but > with an "old" system this worked. Reading the bsd.port.mk, the > "incriminated" CONFIG_DONE rows never changed since the introduction of > the OPTIONS support, so I think this *never* worked as expected. It used to work. I was just guessing about how it might not be working now based on reading the existing logic. I have not delved into the history to see what has changed. -- John Baldwin ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: OPTIONS handling doesn't seem to work fully in dependencies anymore
On Wed, Sep 17, 2008 at 08:52:31AM +0200, Alex Dupre wrote: > Alexey Dokuchaev wrote: > >Nevertheless, going back to rev. 1.559 of b.p.m. restores correct > >behavior. > > Are you sure? I didn't try, but that commit seems to add new reasons to > show up the dialog box while not removing any of the old ones. > Running "make config-recursive" still works (and it calls recursively > "make config-conditional" that works), so it seems john's analysis is > correct, but I cannot figure how (and if) ever worked before. Perhaps I was too fast in my response; I cannot reproduce it now. While I'm trying to continuously approach revision that used to work, I'm starting to suspect that what if it never actually worked? John, how old was your ports tree on 6.x? Maybe this can shed some light on the subject.. ./danfe ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: OPTIONS handling doesn't seem to work fully in dependencies anymore
Alexey Dokuchaev wrote: Nevertheless, going back to rev. 1.559 of b.p.m. restores correct behavior. Are you sure? I didn't try, but that commit seems to add new reasons to show up the dialog box while not removing any of the old ones. Running "make config-recursive" still works (and it calls recursively "make config-conditional" that works), so it seems john's analysis is correct, but I cannot figure how (and if) ever worked before. -- Alex Dupre ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: OPTIONS handling doesn't seem to work fully in dependencies anymore
Doug Barton wrote: John was referring to the problem of 'make config' not being called for ports being installed as dependencies of a port that has OPTIONS. John said (correct me if I'm wrong) that with an up-to-date system OPTIONS doesn't correctly shows up (when the top port has OPTIONS), but with an "old" system this worked. Reading the bsd.port.mk, the "incriminated" CONFIG_DONE rows never changed since the introduction of the OPTIONS support, so I think this *never* worked as expected. -- Alex Dupre ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: OPTIONS handling doesn't seem to work fully in dependencies anymore
On Tue, Sep 16, 2008 at 03:25:12PM -0700, Doug Barton wrote: > Alex Dupre wrote: > > Doug Barton ha scritto: > >> Bug, and at first glance I think your analysis is correct about the > >> cause. > > > > Surely a bug, but the mentioned code is what was added in rev 1.560 > > (http://www.freebsd.org/cgi/cvsweb.cgi/ports/Mk/bsd.port.mk?r1=1.560#rev1.560) > > exactly to add this feature, and AFAIR it worked. > > The commit log refers to a different problem than John reported. The > commit log refers to the problem of a saved options file that doesn't > have all of the new OPTIONS for a new version of the port. > > John was referring to the problem of 'make config' not being called for > ports being installed as dependencies of a port that has OPTIONS. Nevertheless, going back to rev. 1.559 of b.p.m. restores correct behavior. Quite ironically, since commit logs tells us that "The end user impact of this is more blue screens." for rev. 1.560, which I tend to blame now. I also don't think that we can simply tell our users to user portmaster or some force-config switches. This bug is quite annoying, and should be fixed to work in vanilla environment environment with default settings. ./danfe ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: OPTIONS handling doesn't seem to work fully in dependencies anymore
Alex Dupre wrote: > Doug Barton ha scritto: >> Bug, and at first glance I think your analysis is correct about the >> cause. > > Surely a bug, but the mentioned code is what was added in rev 1.560 > (http://www.freebsd.org/cgi/cvsweb.cgi/ports/Mk/bsd.port.mk?r1=1.560#rev1.560) > exactly to add this feature, and AFAIR it worked. The commit log refers to a different problem than John reported. The commit log refers to the problem of a saved options file that doesn't have all of the new OPTIONS for a new version of the port. John was referring to the problem of 'make config' not being called for ports being installed as dependencies of a port that has OPTIONS. Doug -- This .signature sanitized for your protection ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: OPTIONS handling doesn't seem to work fully in dependencies anymore
Doug Barton ha scritto: Bug, and at first glance I think your analysis is correct about the cause. Surely a bug, but the mentioned code is what was added in rev 1.560 (http://www.freebsd.org/cgi/cvsweb.cgi/ports/Mk/bsd.port.mk?r1=1.560#rev1.560) exactly to add this feature, and AFAIR it worked. -- Alex Dupre ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
