On 6/15/15 6:56 AM, Craig Rodrigues wrote:
On Sun, Jun 14, 2015 at 3:37 PM, Adrian Chadd <adr...@freebsd.org
<mailto:adr...@freebsd.org>> wrote:
Hi,
I'm happy for this to be your baby and see how it all pans out
in the
tree, but I thought we as a project learnt some lessons about
checking
in autogenerated files.
Well, I would like to give Simon the benefit of the doubt here.
When I worked at Juniper, I worked first with John Birrell on the
early jbuild prototype, and later with Simon on the bmake + meta-mode
work.
Simon gave this presentation + video on meta-mode at BSDCan 2014:
http://www.bsdcan.org/2014/schedule/track/Hacking/460.en.html
I gave this preso on jbuild at BSDCan 2010:
https://www.bsdcan.org/2010/schedule/events/198.en.html
Inside Juniper, there were concerns expressed about checking in
generated dependency files. I'm seeing the same concerns expressed by
the FreeBSD community. :)
It turns out that checking in the dependency files was the right way
to go.
This has been battle tested inside Juniper, and it does work....I've
seen it.
It turns out that running a dependency generation step at the beginning
of the build takes a long time. When you are building something
on the scale of an operating system, like FreeBSD, or
something even huger, like JUNOS, this takes a non-trivial amount of
time,
and gets worse as the size of the code grows.
Checking in the dependencies allows you to do some pretty amazing
stuff with the build, especially when you start integrating manifests
and packaging of the base system.
Now I will agree with Adrian on a couple of points:
(1) For the initial go around, if Simon babysits the
Makefile.depend files
in HEAD that would be OK. They are turned off by default
anyways.
(2) In the long run, having better documentation, tooling and
procedures to
update the
Makefile.depend files will be definitely needed.
Using automation systems like Jenkins would definitely help,
but that's not the only way to do things.
I think a make MAKE_MAKEFILE_DEPENDS=1 (build)world is an important
step requirement..
i.e. starting with what is there, regenerate ALL of them.. Since the
source tree is supposed to be read-only
this has to not happen by default but if it is possibe to force it,
then svn (or p4 or git) can easily figure out which ones changed (as
long as two runs of the generation pass produce identical output) and
check in any that changed.
--
Craig
_______________________________________________
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
