[GRASS5] ODBC driver build problem

[Frank Warmerdam]

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 at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent