Re: Fwd: [CFT/RFC]: refactor bsd.prog.mk to understand multiple programs instead of a singular program
On Tue, Oct 2, 2012 at 7:37 AM, John Baldwin j...@freebsd.org wrote: On Tuesday, October 02, 2012 10:29:49 am Garrett Cooper wrote: On Tue, Oct 2, 2012 at 4:50 AM, John Baldwin j...@freebsd.org wrote: ... This sounds like a superior approach. It doesn't break any current use cases while giving the ability to build multiple programs in the few places that need it. It sounds like there are a few places under gnu/ from Garrett's reply that might be able to make use of this as well. For the record, gnu/cc/cc_tools/Makefile is where I first spotted a potential bsd.progs.mk candidate. Most of the other code doesn't care given how things are organized in our source tree. BTW, one general comment. There seem to be two completely independent groups of folks working on ATF (e.g. there have been two different imports of ATF into the tree in two different locations IIRC, and now we have two different sets of patches to our system makefiles). Are these two groups talking to each other at all? I know in May that many folks (certainly multiple vendors) are interested in ATF, and it seems that both Juniper and Isilon have ported ATF internally. It seems that it might be good for the two groups to work together to avoid stomping on each other's toes. It seems there are some differences in the two approaches that merit working out to avoid a lot of wasted effort on both sides. Both parties (Isilon/Juniper) are converging on the ATF porting work that Giorgos/myself have done after talking at the FreeBSD Foundation meet-n-greet. I have contributed all of the patches that I have other to marcel for feedback. This is very non-obvious to the public at large (e.g. there was no public response to one group's inquiry about the second ATF import for example). Also, given that you had no idea that sgf@ and obrien@ were working on importing NetBSD's bmake as a prerequisite for ATF, it seems that whatever discussions were held were not very detailed at best. I think it would be good to have the various folks working on ATF to at least summarize the current state of things and sketch out some sort of plan or roadmap for future work in a public forum (such as atf@, though a summary mail would be quite appropriate for arch@). I'm in part to blame for this. There was some discussion -- but not at length; unfortunately no one from Juniper was present at the meet and greet; the information I got was second hand; I didn't follow up to figure out the exact details / clarify what I had in mind with the appropriate parties. That being said, I *sort* of understand what's going on now, although I'm still guessing as I haven't received any FreeBSD internal (developers@, etc) emails and all the discussion I have so far is between gnn@, marcel@, gibbs@, mlaier@, and mdf@. For all intents and purposes I've been paused for a few weeks because of other things, so no harm, no foul, but I'd like to know what all is being contributed back from Juniper in terms of tests, ATF integration into the build system (which I've given back to marcel@/gnn@, but haven't received feedback for yet -- probably because they're busy), etc so I can better avoid duplicated effort and help the cause of creating a maintainable/testable FreeBSD. As far as what Isilon is contributing back, I wouldn't look any further than my perforce repo; the original goal as of last BSDCan was to contribute back `isi_check` (custom wrapper around GNU libcheck), and maybe some of our tests are written for isi_check: the problem with that plan is that it depends on GNU [lib]check -- yet another test infrastructure -- diverges us more unnecessarily from NetBSD (and there are several things we want to grab from NetBSD and contribute back instead of forging ahead down our own path), the tests would need to be audited and cleaned up to use generic macros and check for generic functionality, etc. Also, it would help to have generic system tests similar to LTP's breadth in the tree (so that way we can avoid breakage before things are committed to current). There are some functional gaps that I like to fill in with ATF that GNU libcheck does well [with fixtures] and there are some inconsistencies between the ATF C and C++ bindings I'm working on enhancing More details about what I planned on doing can be found here: http://wiki.freebsd.org/TestingFreeBSD -- although it deserves updating when looking at the structure and dealing with the patches (I need to update it to just work with the latest current). 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: Fwd: [CFT/RFC]: refactor bsd.prog.mk to understand multiple programs instead of a singular program
On Thu, 4 Oct 2012 09:42:29 -0700, Garrett Cooper writes: I'd like to know what all is being contributed back from Juniper in terms of tests, ATF integration into the build system (which I've given back to marcel@/gnn@, but We aim to contribute build improvments, and integration of ATF was part of that. We had planned on doing the ATF import etc, but didn't want to re-invent wheels by trying to make it work without bmake. Or making a dog's breakfast out of bsd.*.mk Speaking of which, the initial commit (which should happen real soon now ;-) is a minimal set of changes to allow buildworld etc using bmake and allow folk who want to, to install bmake as make - as discussed at the last devsummit in Cambridge. Anyway, back to ATF, as mentioned earlier in this thread, I use atf.test.mk in our build rather than netbsd's bsd.test.mk, and we put all the test makefiles in a tests/ subdir of the lib or prog in question. This has important ramifications when it comes to wanting to build the tree in meta mode and have unit-tests build and run as an integral part of the build (or at least the option of doing that). As for meta mode, there is a projects/bmake branch which is a bit out of sync with head, but which I think has meta mode enabled (my internal mirror of it does ;-). It isn't ready for prime-time yet, a lot of the stuff in local.sys.mk there needs to migrate to sys.mk or similar, but that should probably wait until bmake is the default make, and there is also the need for more discussion here. But with a couple of env variables set, people should be able to play with it, to see what we are talking about. The next steps will focus on being able to have bmake the default - which means dealing with ports. I've a patch, that's air-quotes, because I don't think a patch will suffice for a large moving target, rather its a script to run against a ports tree. Once the ports folk are happy that a bmake flavored ports tree can be built and used ok on an older base system, the final cutover can be planned. Hope that helps --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: Fwd: [CFT/RFC]: refactor bsd.prog.mk to understand multiple programs instead of a singular program
On Monday, October 01, 2012 6:31:00 pm Simon J. Gerraty wrote: Hi Garrett, From: Garrett Cooper yaneg...@gmail.com Subject: [CFT/RFC]: refactor bsd.prog.mk to understand multiple = programs instead of a singular program Date: September 2, 2012 11:01:09 PM PDT To: freebsd-hackers@freebsd.org Cc: freebsd-a...@freebsd.org Arch freebsd-a...@freebsd.org =20 Hello, I've been a bit busy working on porting over ATF from NetBSD, and Thanks, we've been using ATF in Junos for a while and glad to see it being imported to FreeBSD. one of the pieces that's currently not available in FreeBSD that's available in NetBSD is the ability to understand and compile multiple programs. In order to do this I had to refactor bsd.prog.mk (a lot). A change like this to bsd.prog.mk can have considerable fallout. Eg. any makefile that tweaks OBJS is suddenly out of luck. Not to mention the fact that bsd.prog.mk goes from being relatively simple, to unspeakably hard to read, and all for rather limited return. Apart from ATF, is there any huge demand for building multiple progs in the same directory? FWIW we use progs.mk (as bsd.progs.mk) from ftp://ftp.netbsd.org/pub/NetBSD/misc/sjg/mk-*.tar.gz It isn't ideal, but it certainly avoids a lot of churn and complexity for what is essentially a corner case. This sounds like a superior approach. It doesn't break any current use cases while giving the ability to build multiple programs in the few places that need it. It sounds like there are a few places under gnu/ from Garrett's reply that might be able to make use of this as well. BTW, one general comment. There seem to be two completely independent groups of folks working on ATF (e.g. there have been two different imports of ATF into the tree in two different locations IIRC, and now we have two different sets of patches to our system makefiles). Are these two groups talking to each other at all? I know in May that many folks (certainly multiple vendors) are interested in ATF, and it seems that both Juniper and Isilon have ported ATF internally. It seems that it might be good for the two groups to work together to avoid stomping on each other's toes. It seems there are some differences in the two approaches that merit working out to avoid a lot of wasted effort on both sides. Do we already have a freebsd-atf@ mailing list? If not, perhaps we should create one and start these discussions there? -- John Baldwin ___ 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: Fwd: [CFT/RFC]: refactor bsd.prog.mk to understand multiple programs instead of a singular program
On Tue, Oct 2, 2012 at 4:50 AM, John Baldwin j...@freebsd.org wrote: ... This sounds like a superior approach. It doesn't break any current use cases while giving the ability to build multiple programs in the few places that need it. It sounds like there are a few places under gnu/ from Garrett's reply that might be able to make use of this as well. For the record, gnu/cc/cc_tools/Makefile is where I first spotted a potential bsd.progs.mk candidate. Most of the other code doesn't care given how things are organized in our source tree. BTW, one general comment. There seem to be two completely independent groups of folks working on ATF (e.g. there have been two different imports of ATF into the tree in two different locations IIRC, and now we have two different sets of patches to our system makefiles). Are these two groups talking to each other at all? I know in May that many folks (certainly multiple vendors) are interested in ATF, and it seems that both Juniper and Isilon have ported ATF internally. It seems that it might be good for the two groups to work together to avoid stomping on each other's toes. It seems there are some differences in the two approaches that merit working out to avoid a lot of wasted effort on both sides. Both parties (Isilon/Juniper) are converging on the ATF porting work that Giorgos/myself have done after talking at the FreeBSD Foundation meet-n-greet. I have contributed all of the patches that I have other to marcel for feedback. Do we already have a freebsd-atf@ mailing list? If not, perhaps we should create one and start these discussions there? Probably wouldn't be a bad idea as I'm currently suspended a bit waiting on feedback for how to proceed; too bad freebsd-test is being used for other things :).. 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: Fwd: [CFT/RFC]: refactor bsd.prog.mk to understand multiple programs instead of a singular program
On Tue, 2 Oct 2012 07:50:23 -0400, John Baldwin writes: BTW, one general comment. There seem to be two completely independent groups of folks working on ATF (e.g. there have been two different imports of ATF into the tree in two different locations IIRC, and now we have two different sets of patches to our system makefiles). Yes, and no. We (Juniper) have been using ATF for some time, and were going to do import etc, but for various reasons haven't done it yet. In part I guess because having bmake in tree would have made things much simpler - avoiding re-inventing wheels. Garrett, has forged ahead, and we are fine with that - Marcel did the import for him. Obviously though (as I've probably just made clear) we don't want ATF to unnecessarily complicate the build. We hope to get the initial bmake commit done this week, and then we can help Garrett get ATF going with minimal fuss. Are these two groups talking to each other at all? Yes, but I don't think Garrett was aware of the bmake work. It seems there are some differences in the two approaches that merit working out to avoid a lot of wasted effort on both sides. The differences are probably very minor, and hopefully easily sorted out. The most significant being how to build the multiple test apps in one directory. Related to that is the exact location. I believe we are all agreed that tests should be co-located with the code they exercise - to facilitate testing as you make changes. We use a tests/ subdir per lib and prog that has unit-tests and I would recommend doing the same. This is consistent with the above goal, and the separate directory is very useful for keeping the build simple - eg. libfoo/Makefile can continue to just use bsd.lib.mk while libfoo/tests/Makefile can use any of bsd.prog.mk, bsd.progs.mk, bsd.test.mk or atf.test.mk Also, these separate dirs become even more important when using meta mode because you want the all/default target to just do the right thing, and do it the same way every time, to avoid churn in dependencies. Do we already have a freebsd-atf@ mailing list? If not, perhaps we should create one and start these discussions there? Don't know, but fine either way. --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: Fwd: [CFT/RFC]: refactor bsd.prog.mk to understand multiple programs instead of a singular program
On Tuesday, October 02, 2012 10:29:49 am Garrett Cooper wrote: On Tue, Oct 2, 2012 at 4:50 AM, John Baldwin j...@freebsd.org wrote: ... This sounds like a superior approach. It doesn't break any current use cases while giving the ability to build multiple programs in the few places that need it. It sounds like there are a few places under gnu/ from Garrett's reply that might be able to make use of this as well. For the record, gnu/cc/cc_tools/Makefile is where I first spotted a potential bsd.progs.mk candidate. Most of the other code doesn't care given how things are organized in our source tree. BTW, one general comment. There seem to be two completely independent groups of folks working on ATF (e.g. there have been two different imports of ATF into the tree in two different locations IIRC, and now we have two different sets of patches to our system makefiles). Are these two groups talking to each other at all? I know in May that many folks (certainly multiple vendors) are interested in ATF, and it seems that both Juniper and Isilon have ported ATF internally. It seems that it might be good for the two groups to work together to avoid stomping on each other's toes. It seems there are some differences in the two approaches that merit working out to avoid a lot of wasted effort on both sides. Both parties (Isilon/Juniper) are converging on the ATF porting work that Giorgos/myself have done after talking at the FreeBSD Foundation meet-n-greet. I have contributed all of the patches that I have other to marcel for feedback. This is very non-obvious to the public at large (e.g. there was no public response to one group's inquiry about the second ATF import for example). Also, given that you had no idea that sgf@ and obrien@ were working on importing NetBSD's bmake as a prerequisite for ATF, it seems that whatever discussions were held were not very detailed at best. I think it would be good to have the various folks working on ATF to at least summarize the current state of things and sketch out some sort of plan or roadmap for future work in a public forum (such as atf@, though a summary mail would be quite appropriate for arch@). -- John Baldwin ___ 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: Fwd: [CFT/RFC]: refactor bsd.prog.mk to understand multiple programs instead of a singular program
Hi Garrett, From: Garrett Cooper yaneg...@gmail.com Subject: [CFT/RFC]: refactor bsd.prog.mk to understand multiple = programs instead of a singular program Date: September 2, 2012 11:01:09 PM PDT To: freebsd-hackers@freebsd.org Cc: freebsd-a...@freebsd.org Arch freebsd-a...@freebsd.org =20 Hello, I've been a bit busy working on porting over ATF from NetBSD, and Thanks, we've been using ATF in Junos for a while and glad to see it being imported to FreeBSD. one of the pieces that's currently not available in FreeBSD that's available in NetBSD is the ability to understand and compile multiple programs. In order to do this I had to refactor bsd.prog.mk (a lot). A change like this to bsd.prog.mk can have considerable fallout. Eg. any makefile that tweaks OBJS is suddenly out of luck. Not to mention the fact that bsd.prog.mk goes from being relatively simple, to unspeakably hard to read, and all for rather limited return. Apart from ATF, is there any huge demand for building multiple progs in the same directory? FWIW we use progs.mk (as bsd.progs.mk) from ftp://ftp.netbsd.org/pub/NetBSD/misc/sjg/mk-*.tar.gz It isn't ideal, but it certainly avoids a lot of churn and complexity for what is essentially a corner case. We have an atf.test.mk which leverages that. It also handles automatically running the tests if building for the host. This allows us to fail the build if any unit-tests do not pass. Note, atf.test.mk is loosely derrived from NetBSD's bsd.tests.mk, but named for what it is (ATF specific tests) since we wanted the flexibility to have more than one test framework. --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
