My take on env vars has less to do with make and more of my school of thought keeping dependency binaries out of CVS. I view CVS as a _source_ control medium, not a build repository. Env vars are the logical choice for making clean builds when engaging in that school of thought.
And you're right. When I first time got the Hibernate sources from CVS, I was annoyed by the fact it has lib/*.jar in it, while I have most of them (commons-*, junit, log4j, ...) locally. I was expected a kind of build.properties where I could easely specify the location of these jars.
Even stupid users can be teached to specify correct properties by simply testing it, smth like:
<fail unless="junit.jar"
message="UNCONFIGURED: copy build.properties.dist into
build.properties and adjust locations in it"/>where junit.jar is the property specified in build.properties. build.properties.dist is the default locations and this file is in CVS. build.properties is system-dependent, and is created at every compilation host (once).
One may say that build.properties is not ENVs, but actually it IS.
Again, I'm just happy to contribute to Hibernate, and will of course follow the consensus whenever messing with the CVS tree... :)
But *I am* unhappy. I'm not contributor, at least not permanent, but the current sources organization is bulky and ... and dumb.
dozen
------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ hibernate-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hibernate-devel
