[ntp:hackers] how to update docs, add keywords, add opts, etc.
hmurray at megapathdsl.net
Sat Aug 10 02:59:06 UTC 2013
I think the answer to many of your questions is just-type-make. It should do
the right thing. If not, we should fix it. [I assume Harlan will correct me
if I'm wrong.]
Of course, before you can do that you have to run configure. Configure will
work out of a tar file, but if you are using BK, you need to run bootstrap
There is actually another step before that. The parser for ntp.conf gets
compiled someplace and the output of that step is fed into BK as source.
There may be other files treated this way. I think the idea is to not
require tools (bison) on all systems where people might be running BK.
There is a layer of stuff in the Makefiles that tries to avoid doing
unnecessary work. The one I saw the other day made a new version of xxx and
compared it to the old version after removing both the time-stamp lines in
both files. If there was no change (except the time stamps), it didn't
update the old version of xxx.
If it were up to me, I think I would remove all that stuff. Computers are
fast enough now that it's not a serious problem to do a few extra compiles.
I think simplifying the Makefiles and build process would be a good trade.
[For reference, it's 2-5 minutes to do a configure and make. That's using a
local disk on a PC. I'll get solid numbers if anybody wants.]
Of course, you have to know what to edit. Harlan's message covered much of
that, but it would be nice to collect all that knowledge in one place.
Many years ago, I remember when I found the memo describing the flow of our
CAD system. Wow, all of a sudden a whole bunch of stuff made sense. A
similar memo/web page/README/whatever for the NTP world would be a big help.
I'll be glad to help, but I don't know a lot of the details.
brian.utterback at oracle.com said:
> Oh, and one last thing. Once I get everything up to data, is there a
> procedure for how to create a distribution tarball from the updated repo? I
> would like to take the tarball and test it on my target systems.
If you just want to test your new code on several systems rather than make
sure that you can build a tarball that will work, you can just get the whole
directory to the other machine any way you like. I use rsync. NFS works too.
If you are using NFS, you have to make sure that various machines don't
trample on eachother. The Makefiles are setup to support that. I call it
building-off-to-the-side. There may be a buzzword, but I don't know it.
The basic idea is:
The compiler reaches back to the source directory get the input files but all
the output gets left in <hostname>. You can blow away that whole directory
any time you want.
If you are editing things like the parser for config files (ntp_parser.y),
the output gets left back in the source directory. bk status -v will find it.
If you are testing on multiple machines, it's fairly easy to put most of the
work into scripts. I started with one that does a bk pull and bootstrap so I
don't forget the bootstrap step. I keep the per-machine configuration info
in configure.<hostname>, so the configure step above becomes
../configure.<hostname>, and I have a do-local-build script that does all the
above and tee-s the output off to config.log and make.log
These are my opinions. I hate spam.
More information about the hackers