Glynn Clements wrote:
What does the "DBMI DRIVERS" section of src/CMD/lists/GRASS look like?
It should look like this:
##### DBMI DRIVERS ##### src/libes/dbmi/lib
src/libes/dbmi/drivers/stubs
Do you have src/CMD/lists/local or src/CMD/lists/<architecture> files?
At present, the build process doesn't include any logic to
conditionally build a particular library or program according to
whether you have the required dependencies.
Instead, it attempts to build every directory which is listed in
src/CMD/lists/{GRASS,local,<architecture>}.
Glynn,
The local file is correct now, and the build seems to run properly, not
trying to build the odbc driver. I believe the problem is that I hadn't
rerun configure after updating to the release branch, got the odbc problem.
I then reran configure but kept running gmake5 in the libes/dbmi directory
which resulted in the extra odbc driver build be attempted. When I reran
the full make after the reconfigure the build ran fine.
What is gmake5 under the hood? Is it just a script setting up makefiles
for old style (non-GNU) make? If we were willing to specify GNUmake
as a build requirement we could have the makefiles decide what subdirs to
build based on variables setup by configure pretty easily.
Amoung other problems, the existing Gmakefile and list of places to
build is hard to grok for developers new to GRASS.
A few other "developer" questions:
o How do folks normally do quick global builds when they just want to
refresh things. I find the current mechanisms insistance on reprocessing
all the html/man stuff makes it very slow to do a top level make.
o Do developers normally do a "make install", and run from the installed tree
during development, or somehow run directly from their build tree? When I am just making iterative improvements to a program I have adopted
the practice of just doing a gmake5 in that programs directory, and replacing
the binary in the installed tree with a link back to the executable in the
build tree. But this is somewhat tedious to steup, and I would presume other
folks have a smoother approach.
PS. I am building from the latest stable despite the warning Glynn
sent because I am afraid I might have been the one to botch CVS.
Did you check out the development branch then commit the entire tree
to the release branch? That might explain it.
I certainly don't think I did any global commits, but it is possible I did. I am normally very careful to commit only specific file lists.
However, I looked into some of the items folks mentioned were screwed up now
and couldn't find any suggestion that I had made any sort of commit to the
files.
Best regards,
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent