Re: FreeBSD in Google Code-In 2012? You can help too!
2012/10/25 Pedro Giffuni p...@freebsd.org (cc'ing -ports and cutting most of the rest) From: Eitan Adler . On 24 October 2012 13:24, Fernando Apesteguía wrote: Also related to that, what about writing a section about redports[1] in the porter's handbook[2]? This is a good documentation task... but we need more *coding* tasks as well. We do need to port and test patch (1) from NetBSD or DragonFly to replace GNU patch, and this shouldn't be difficult. I would guess there are other interesting possibilities in the ports tree and new ports count as coding: http://wiki.freebsd.org/WantedPorts Interesting, there is mentioned LWJGL, while I have patch for native build for about a year. I poked upstream about it again, I hope they will apply it in next version. So i guess we need porting mentors. Pedro. ___ freebsd-po...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org -- Regards, Alexander Yerenkow ___ 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: [CFT/RFC]: refactor bsd.prog.mk to understand multiple programs instead of a singular program
On Mon, Oct 08, 2012 at 09:11:29AM -0700, Marcel Moolenaar wrote: two independent efforts (ATF bmake) and there was no indication that one would be greatly benefitted from the other. At least not to the point of creating a dependency. It seems we do have the situation where folks feel there is a dependency between the two. Before we can switch permanently to bmake, we need to do the following first: 1. Request an EXP ports build with bmake as make(1). This should tell us the damage of switching to bmake for ports. 2. In parallel with 1: build www docs with bmake and assess the damage 3. Fix all the damage It could be a while (many weeks) before we get to 4, so the question Given the time this will take, I feel we need to add another knob to the Bmake build so that 'make world' gives one both the FreeBSD make as /usr/bin/make and Bmake as /usr/bin/bmake. thoughts, -- -- 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: [CFT/RFC]: refactor bsd.prog.mk to understand multiple programs instead of a singular program
On 25 October 2012 22:15, David O'Brien obr...@freebsd.org wrote: On Mon, Oct 08, 2012 at 09:11:29AM -0700, Marcel Moolenaar wrote: two independent efforts (ATF bmake) and there was no indication that one would be greatly benefitted from the other. At least not to the point of creating a dependency. It seems we do have the situation where folks feel there is a dependency between the two. Before we can switch permanently to bmake, we need to do the following first: 1. Request an EXP ports build with bmake as make(1). This should tell us the damage of switching to bmake for ports. 2. In parallel with 1: build www docs with bmake and assess the damage 3. Fix all the damage It could be a while (many weeks) before we get to 4, so the question Given the time this will take, I feel we need to add another knob to the Bmake build so that 'make world' gives one both the FreeBSD make as /usr/bin/make and Bmake as /usr/bin/bmake. We really aren't going to have any luck yet... [crees@pegasus]/usr/ports% sudo make MAKE=/usr/bin/bmake index | head Generating INDEX-9 - please wait..bmake: /usr/ports/Mk/bsd.port.mk line 5127: warning: duplicate script for target -depends ignored bmake: /usr/ports/Mk/bsd.port.mk line 5124: warning: using previous script for -depends defined here bmake: /usr/ports/Mk/bsd.port.mk line 5127: warning: duplicate script for target -depends ignored bmake: /usr/ports/Mk/bsd.port.mk line 5124: warning: using previous script for -depends defined here bmake: /usr/ports/Mk/bsd.port.mk line 5127: warning: duplicate script for target -depends ignored bmake: /usr/ports/Mk/bsd.port.mk line 5124: warning: using previous script for -depends defined here bmake: /usr/ports/Mk/bsd.port.mk line 5124: warning: duplicate script for target -depends ignored bmake: /usr/ports/Mk/bsd.port.mk line 5124: warning: using previous script for -depends defined here bmake: /usr/ports/Mk/bsd.port.mk line 5124: warning: duplicate script for target -depends ignored bmake: /usr/ports/Mk/bsd.port.mk line 5124: warning: using previous script for -depends defined here Looks like a few missing .if !target s, but the breakage is pretty big even for simple things :/ Chris ___ 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: [CFT/RFC]: refactor bsd.prog.mk to understand multiple programs instead of a singular program
On Oct 25, 2012, at 2:15 PM, David O'Brien obr...@freebsd.org wrote: On Mon, Oct 08, 2012 at 09:11:29AM -0700, Marcel Moolenaar wrote: two independent efforts (ATF bmake) and there was no indication that one would be greatly benefitted from the other. At least not to the point of creating a dependency. It seems we do have the situation where folks feel there is a dependency between the two. Before we can switch permanently to bmake, we need to do the following first: 1. Request an EXP ports build with bmake as make(1). This should tell us the damage of switching to bmake for ports. 2. In parallel with 1: build www docs with bmake and assess the damage 3. Fix all the damage It could be a while (many weeks) before we get to 4, so the question Given the time this will take, I feel we need to add another knob to the Bmake build so that 'make world' gives one both the FreeBSD make as /usr/bin/make and Bmake as /usr/bin/bmake. I think there are 2 reasons why not to: 1. The people working on ATF have not raised this concern and have expressed that using the WITH_BMAKE knob is but a small price to pay. So let's work the bmake side and be able to get rid of the knob as soon as possible. 2. More knobs isn't better -- we must have none of the knobs in the end, so the more we create, the more work we have to get rid of them. That's just more work spent not focusing on the task at hand and thus more time wasted. In short: this isn't a 2-knob problem by any stretch of the imagination. -- Marcel Moolenaar mar...@xcllnt.net ___ 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: [CFT/RFC]: refactor bsd.prog.mk to understand multiple programs instead of a singular program
On Thu, Oct 25, 2012 at 2:23 PM, Marcel Moolenaar mar...@xcllnt.net wrote: ... I think there are 2 reasons why not to: 1. The people working on ATF have not raised this concern and have expressed that using the WITH_BMAKE knob is but a small price to pay. So let's work the bmake side and be able to get rid of the knob as soon as possible. It is annoying with the magnitude of build-related errors, but I have a workaround. 2. More knobs isn't better -- we must have none of the knobs in the end, so the more we create, the more work we have to get rid of them. That's just more work spent not focusing on the task at hand and thus more time wasted. Yes, but not being able to update one's machine makes me sad panda. In short: this isn't a 2-knob problem by any stretch of the imagination. 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. 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
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 yaneg...@gmail.com 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
Re: [CFT/RFC]: refactor bsd.prog.mk to understand multiple programs instead of a singular program
On 25 October 2012 22:32, Garrett Cooper yaneg...@gmail.com wrote: On Thu, Oct 25, 2012 at 2:23 PM, Marcel Moolenaar mar...@xcllnt.net wrote: ... I think there are 2 reasons why not to: 1. The people working on ATF have not raised this concern and have expressed that using the WITH_BMAKE knob is but a small price to pay. So let's work the bmake side and be able to get rid of the knob as soon as possible. It is annoying with the magnitude of build-related errors, but I have a workaround. 2. More knobs isn't better -- we must have none of the knobs in the end, so the more we create, the more work we have to get rid of them. That's just more work spent not focusing on the task at hand and thus more time wasted. Yes, but not being able to update one's machine makes me sad panda. In short: this isn't a 2-knob problem by any stretch of the imagination. 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. Now you've terrified me, and probably most other ports people too. Is there a Wiki page where the actual benefits of moving to bmake are made clear? This is a major, *major* upheaval, and having two versions of bsd.port.mk for years is simply not an option. Have you discussed this on ports@? Chris ___ 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: [CFT/RFC]: refactor bsd.prog.mk to understand multiple programs instead of a singular program
On Thu, Oct 25, 2012 at 11:01:27PM +0100, Chris Rees wrote: On 25 October 2012 22:32, Garrett Cooper yaneg...@gmail.com wrote: On Thu, Oct 25, 2012 at 2:23 PM, Marcel Moolenaar mar...@xcllnt.net wrote: ... I think there are 2 reasons why not to: 1. The people working on ATF have not raised this concern and have expressed that using the WITH_BMAKE knob is but a small price to pay. So let's work the bmake side and be able to get rid of the knob as soon as possible. It is annoying with the magnitude of build-related errors, but I have a workaround. 2. More knobs isn't better -- we must have none of the knobs in the end, so the more we create, the more work we have to get rid of them. That's just more work spent not focusing on the task at hand and thus more time wasted. Yes, but not being able to update one's machine makes me sad panda. In short: this isn't a 2-knob problem by any stretch of the imagination. 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. Now you've terrified me, and probably most other ports people too. Is there a Wiki page where the actual benefits of moving to bmake are made clear? This is a major, *major* upheaval, and having two versions of bsd.port.mk for years is simply not an option. Not much test has been done on the ports tree about it, from what I have tested so far, except from the :tu :tl difference the ports seems to work ootb with both bmake and make, I asked obrien to MFC the support for :tl :tu in make(1) to all available platform which he did. Do be able to get the ports tree working with bmake asap, I also asked him to MFC it to 9.1, from latest reply he got positive answer from re@ about this, but was waiting for something I don't remember. regards, Bapt pgpp7TctkVsBS.pgp Description: PGP signature
Re: [CFT/RFC]: refactor bsd.prog.mk to understand multiple programs instead of a singular program
On 25 October 2012 18:12, Baptiste Daroussin b...@freebsd.org wrote: Not much test has been done on the ports tree about it, from what I have tested so far, except from the :tu :tl difference the ports seems to work ootb with both bmake and make, I asked obrien to MFC the support for :tl :tu in make(1) to all available platform which he did. Do be able to get the ports tree working with bmake asap, I also asked him to MFC it to 9.1, from latest reply he got positive answer from re@ about this, but was waiting for something I don't remember. The ports tree isn't the only concern. We also need to think about upstream users of bmake that relied on :U and the like working as it does now. We will either need to patch them, or implement a USE_OLD_MAKE flag. -- Eitan Adler ___ 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: [CFT/RFC]: refactor bsd.prog.mk to understand multiple programs instead of a singular program
On Thu, Oct 25, 2012 at 3:01 PM, Chris Rees cr...@freebsd.org wrote: ... Now you've terrified me, and probably most other ports people too. Is there a Wiki page where the actual benefits of moving to bmake are made clear? This is a major, *major* upheaval, and having two versions of bsd.port.mk for years is simply not an option. I'm not the best advocate for bmake vs pmake; like bapt@ said in the followup email, most things work out of the box where people aren't trying to be clever, but I've found some interesting edgecases where bmake works and pmake doesn't, and vice versa because the old code depends upon incorrect behavior. I wasn't necessarily advocating having two bsd.*.mk files as the best idea -- it's just what came to mind first. Have you discussed this on ports@? I haven't, but I hope that someone else started this discussion... Thanks, -Garrett PS I am an optimist, but I'm a realist more than an optimist. I know that changing major/fundamental system components like make, the toolchain, etc requires a good deal of testing and there will be bugs/issues that need to be resolved. We just should make sure that things work as best possible for those looking back as well as those looking forward because it's considerably easier doing development on FreeBSD when I can just update a ports tree, build on 6.x/7.2/7.3, run some quick tests, then switch up to 10 and do other development. ___ 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: [CFT/RFC]: refactor bsd.prog.mk to understand multiple programs instead of a singular program
On Thu, 25 Oct 2012 22:21:59 +0100, Chris Rees writes: We really aren't going to have any luck yet... [crees@pegasus]/usr/ports% sudo make MAKE=/usr/bin/bmake index | head If anyone is eager to play with this, I just have put a copy of ports2bmake.tar.gz in ~sjg/ on freefall. This contains a script that *should* convert ports to bmake syntax, while adding a hack to allow older systems to still work. It will generate a list of all the files it frobs so you can easily revert them - eg. before updating the tree. There's a README file in the tarball which hopefully explains all. Any issues - pls let me know. --sjg ___ 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: [CFT/RFC]: refactor bsd.prog.mk to understand multiple programs instead of a singular program
On Thu, Oct 25, 2012 at 10:21:59PM +0100, Chris Rees wrote: On 25 October 2012 22:15, David O'Brien obr...@freebsd.org wrote: On Mon, Oct 08, 2012 at 09:11:29AM -0700, Marcel Moolenaar wrote: two independent efforts (ATF bmake) and there was no indication that one would be greatly benefitted from the other. At least not to the point of creating a dependency. It seems we do have the situation where folks feel there is a dependency between the two. Before we can switch permanently to bmake, we need to do the following first: 1. Request an EXP ports build with bmake as make(1). This should tell us the damage of switching to bmake for ports. 2. In parallel with 1: build www docs with bmake and assess the damage 3. Fix all the damage It could be a while (many weeks) before we get to 4, so the question Given the time this will take, I feel we need to add another knob to the Bmake build so that 'make world' gives one both the FreeBSD make as /usr/bin/make and Bmake as /usr/bin/bmake. We really aren't going to have any luck yet... [crees@pegasus]/usr/ports% sudo make MAKE=/usr/bin/bmake index | head Generating INDEX-9 - please wait..bmake: /usr/ports/Mk/bsd.port.mk line 5127: warning: duplicate script for target -depends ignored bmake: /usr/ports/Mk/bsd.port.mk line 5124: warning: using previous script for -depends defined here bmake: /usr/ports/Mk/bsd.port.mk line 5127: warning: duplicate script for target -depends ignored bmake: /usr/ports/Mk/bsd.port.mk line 5124: warning: using previous script for -depends defined here bmake: /usr/ports/Mk/bsd.port.mk line 5127: warning: duplicate script for target -depends ignored bmake: /usr/ports/Mk/bsd.port.mk line 5124: warning: using previous script for -depends defined here bmake: /usr/ports/Mk/bsd.port.mk line 5124: warning: duplicate script for target -depends ignored bmake: /usr/ports/Mk/bsd.port.mk line 5124: warning: using previous script for -depends defined here bmake: /usr/ports/Mk/bsd.port.mk line 5124: warning: duplicate script for target -depends ignored bmake: /usr/ports/Mk/bsd.port.mk line 5124: warning: using previous script for -depends defined here Looks like a few missing .if !target s, but the breakage is pretty big even for simple things :/ Have you converted the :U to :tu and :L to :tl? regards, Bapt pgpGGmrYitgPo.pgp Description: PGP signature
Re: [CFT/RFC]: refactor bsd.prog.mk to understand multiple programs instead of a singular program
On Thu, 25 Oct 2012 23:01:27 +0100, Chris Rees writes: Is there a Wiki page where the actual benefits of moving to bmake are made clear? This is a major, *major* upheaval, and having two versions of bsd.port.mk for years is simply not an option. There is no need/plan for two versions of bsd.port.mk, the patch I just mentioned, deals with older systems by detecting that bmake was not used, and using it (installing if need be). Have you discussed this on ports@? I have not at least. This was discussed at the last couple of BSDCan's and dev summits. The original plan discussed at BSDCan a couple of years ago, was to allow bmake and the old make to cooexist for some time so that ports could continue to use the old make. At the last BSDCan we were told that wasn't an option - hence the patch to ports that was mentioned. FWIW the changes to 99.9% of the ports tree are trivial (:L - :tl etc). The only interesting changes are to bsd.port.mk (the diff other than the above is 54 lines) they cover 2 things - dealing with old make as mentioned above, and man pages. The nested .for loops that deal with MLINKS are replaced with one line - this was safer that attempting to hack those .for loops to work with both makes. --sjg ___ 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: [CFT/RFC]: refactor bsd.prog.mk to understand multiple programs instead of a singular program
On Thu, Oct 25, 2012 at 03:53:53PM -0700, Simon J. Gerraty wrote: On Thu, 25 Oct 2012 23:01:27 +0100, Chris Rees writes: Is there a Wiki page where the actual benefits of moving to bmake are made clear? This is a major, *major* upheaval, and having two versions of bsd.port.mk for years is simply not an option. There is no need/plan for two versions of bsd.port.mk, the patch I just mentioned, deals with older systems by detecting that bmake was not used, and using it (installing if need be). Have you discussed this on ports@? I have not at least. This was discussed at the last couple of BSDCan's and dev summits. The original plan discussed at BSDCan a couple of years ago, was to allow bmake and the old make to cooexist for some time so that ports could continue to use the old make. At the last BSDCan we were told that wasn't an option - hence the patch to ports that was mentioned. FWIW the changes to 99.9% of the ports tree are trivial (:L - :tl etc). The only interesting changes are to bsd.port.mk (the diff other than the above is 54 lines) they cover 2 things - dealing with old make as mentioned above, and man pages. The nested .for loops that deal with MLINKS are replaced with one line - this was safer that attempting to hack those .for loops to work with both makes. I am watching the serial for some time. Could please, someone, describe why bmake cannot grow the compat features to be a drop-in replacement for FreeBSD make, instead of patching all the trees ? In particular, why cannot the ':L' and ':U' support be added ? pgpZs4ID2dTbM.pgp Description: PGP signature
