[Condor-devel] change in how to build condor in 6.8.x and beyond

[Derek Wright <wright@xxxxxxxxxxx>]

part of the changes i made in the TRUNK between the time i merged  
V6_7-branch in and when i created the V6_8-branch were to fix an  
issue that's been driving me nuts and creating a lot of problems (and  
work) for condor developers -- how we handle config.h.in.

------------------------------
short version:
------------------------------

to build condor, once you check-out from source, you should now run  
the "build_init" script in src.  this will check for the right  
versions of autoconf and autoheader, and run them to automatically  
generate a configure script and a valid config.h.in file.  this is  
already done for you if you use "new_workspace", and the nightly  
condor builds in NMI already do this.  so, this should only effect  
you if:

a) you setup your own build workspaces without new_workspace
or
b) you make changes to configure.ac and want to test them

in general, the new procedure for building condor should be:
1) get sources (cvs checkout, tarball, whatever)
2) cd src; ./build_init
3) ./configure
4) make


------------------------------
long version:
------------------------------

config.h.in is a file that's automatically generated by the  
"autoheader" tool by reading input from configure.ac.  it is the  
template that is converted into the real config.h once you run the  
configure script on a given platform.  when i first converted our  
build system to use config.h, i didn't want to change the process by  
which folks were accustomed to building condor, so i just committed  
the auto-generated config.h.in directly to src.  then, whenever  
someone changed configure.ac in a way that would cause a change in  
config.h.in, we had to remember to commit the new version of  
config.h.in.  this meant that folks touching configure.ac had to know  
about this mess, but most folks building condor did not.

however, this is a pain in the ass, and very error prone.  lots of  
people would change configure.ac in a way that required a new  
config.h.in but didn't realize they left the older, stale copy in the  
repository.  ultimately, getting condor developers to run autoheader  
themselves is the right solution.  however, by using a script for  
this we can a) check for the right versions of the tools (we  
currently require autoconf 2.59) and b) in the future, if we start  
using automake or something, the build process will remain the same,  
even if the steps taken by build_init have to change.


as always, if anyone has any questions, please ask.

thanks,
-derek

p.s. if there was an authoritative document on how to build condor  
from source, i'd update it, but given our current maze of scattered  
development docs, i'm not even sure what doc to edit. :(  this will  
all be changing in the near future as we move to a centralized,  
unified content management system (more on this later).