Re: Installing make as pmake when WITH_BMAKE specified (was Re: [CFT/RFC]: refactor bsd.prog.mk to understand multiple programs instead of a singular program)
Can someone please explain to me what the original reason is for causing such ridiculously large, far reaching issues? And why people seem to be in a really, really big rush for it? Adrian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Installing make as pmake when WITH_BMAKE specified (was Re: [CFT/RFC]: refactor bsd.prog.mk to understand multiple programs instead of a singular program)
On Fri, Oct 26, 2012 at 09:34:20AM -0700, David O'Brien wrote: > (there are no pre-build packages for 10-CURRENT). Please see the first two entries on: http://pkgbeta.freebsd.org/ mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Installing make as pmake when WITH_BMAKE specified (was Re: [CFT/RFC]: refactor bsd.prog.mk to understand multiple programs instead of a singular program)
On Fri, Oct 26, 2012 at 9:34 AM, David O'Brien wrote: > On Thu, Oct 25, 2012 at 03:00:21PM -0700, Garrett Cooper wrote: >> Here's an updated version of the workaround that works properly in all >> cases and installs bmake as make and links make to pmake when >> WITH_BMAKE=yes, and installs make as make when WITHOUT_BMAKE is >> specified (this works better than the previous patch I sent to Simon). > > Garrett, > I don't see how this could be committed -- it will make it difficult > for 10-CURRENT folks to build ports (and there are no pre-build packages > for 10-CURRENT). I don't want it committed because Simon's move makes sense longterm: I wanted to offer an alternative as opposed to just being stuck in purgatory and figured that others might benefit from it. We're stuck at a point now that we need to make a break but we also need to ensure that we don't break things too badly for users with older versions of make. Installing our version of make as something other than `make` would at least allow us to use make as pmake in ports, but I realized it would requiring hacking around portmaster, portupgrade, and a number of other tools that expect FreeBSD make to be make and don't have a means of parameterizing make in the environment or on the command line. So looking back now my mitigation solution would not be ideal and would not fix any problems really. > Are you not able to use this instead (w/"WANT_USRBIN_BMAKE=" in > /etc/src.conf)? That would be interesting too (and is a lot less involved than my patch), and probably would have less fallout. Thanks! -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Installing make as pmake when WITH_BMAKE specified (was Re: [CFT/RFC]: refactor bsd.prog.mk to understand multiple programs instead of a singular program)
>with their use of FreeBSD's make in their own projects. So picking a >good name now would be helpful. FWIW I keep a copy in /usr/bin/fmake so I can compare behavior. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Installing make as pmake when WITH_BMAKE specified (was Re: [CFT/RFC]: refactor bsd.prog.mk to understand multiple programs instead of a singular program)
On Thu, Oct 25, 2012 at 03:00:21PM -0700, Garrett Cooper wrote: > Here's an updated version of the workaround that works properly in all > cases and installs bmake as make and links make to pmake when > WITH_BMAKE=yes, and installs make as make when WITHOUT_BMAKE is > specified (this works better than the previous patch I sent to Simon). Also, please note we have a 'pmake' port that is the proper original pmake (before *BSD embellished it). Perhaps a different name than 'pmake' is appropriate. It would not surprise me for someone to end up adding a port of the current FreeBSD make in case there are folks that find bmake incompatible with their use of FreeBSD's make in their own projects. So picking a good name now would be helpful. -- -- David (obr...@freebsd.org) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Installing make as pmake when WITH_BMAKE specified (was Re: [CFT/RFC]: refactor bsd.prog.mk to understand multiple programs instead of a singular program)
On Thu, Oct 25, 2012 at 03:00:21PM -0700, Garrett Cooper wrote:
> Here's an updated version of the workaround that works properly in all
> cases and installs bmake as make and links make to pmake when
> WITH_BMAKE=yes, and installs make as make when WITHOUT_BMAKE is
> specified (this works better than the previous patch I sent to Simon).
Garrett,
I don't see how this could be committed -- it will make it difficult
for 10-CURRENT folks to build ports (and there are no pre-build packages
for 10-CURRENT).
Are you not able to use this instead (w/"WANT_USRBIN_BMAKE=" in /etc/src.conf)?
Index: usr.bin/Makefile
===
--- usr.bin/Makefile(revision 241927)
+++ usr.bin/Makefile(working copy)
@@ -281,6 +281,9 @@ SUBDIR+=msgs
.if ${MK_BMAKE} != "no"
SUBDIR+= bmake
.else
+.if defined(WANT_USRBIN_BMAKE)
+SUBDIR+= bmake
+.endif
SUBDIR+= make
.endif
.endif
--
-- David (obr...@freebsd.org)
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Installing make as pmake when WITH_BMAKE specified (was Re: [CFT/RFC]: refactor bsd.prog.mk to understand multiple programs instead of a singular program)
On Thu, Oct 25, 2012 at 2:32 PM, Garrett Cooper wrote: ... > The real issue is that I need to take the patch Simon developed, run > with it, and in parallel he needs to -- and hopefully already is -- > engage portmgr to get it through a number of exp- runs to make sure > bmake does what it's supposed to do with his patch. Backwards > compatibility will need to be maintained for ports because ports has > to work on multiple versions of FreeBSD [where bmake isn't yet > available/present], so maybe a fork in the road for bsd.port.mk should > be devised in order to make everything work. Here's an updated version of the workaround that works properly in all cases and installs bmake as make and links make to pmake when WITH_BMAKE=yes, and installs make as make when WITHOUT_BMAKE is specified (this works better than the previous patch I sent to Simon). The point of the patch isn't to discourage bmake use; in fact this encourages bmake use more because I'm able to use bmake as my system make, but be able to fall back to pmake as needed. Thanks! -Garrett install-make-as-pmake-when-WITH_BMAKE-specified.patch Description: Binary data ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
