Re: [AMBER-Developers] need suggestions about Amber12 build/test procedure

From: B. Lachele Foley <lfoley.uga.edu>
Date: Wed, 15 Feb 2012 16:39:59 +0000

"Like Dave says, this is certainly possible, but it's not what I thought you
were advocating. I thought you wanted to enable both a parallel build
_and_ a serial build within the same config.h file. This approach is what
I said would require reworking (since several places make an assumption
that a config.h file _either_ specifies a parallel or a serial build). I
think it would be straightforward to change, but we all know how
straightforward such things really are."

I agree that hanging on to a config file for later only makes sense in a few circumstances. If you have, say, xlibs or mpi libs in a weird place or something, which requires hacking the file, it can be good to hang on to the last known version that worked. Used to be, too (and maybe still?), say circa amber 8, that you had to compile separately for some things, like 10-12 LJ support. In those cases, the tree didn't change at all. It's just that six months later someone would say "oh, can you recompile sander with...", and that job would be simpler if I'd saved the old config file. The automated build never seemed to "just work" back then, so I almost always had to change it by hand.

Anyhow,it was that memory that made me think you could build a config_serial.h and a config_parallel.h at the start. Then, you could have the makefile set symbolic links to each from config.h (or just copy them). It would be something like:

make serial config file
make parallel config file
set config.h to be the serial one
make install
check for errors, stop if there are any
make clean
set config.h to the parallel one
make install
check for errors...

"I agree with the rest of Dave's comments below."

Sure, me, too, in most cases. But, there are exceptions. I wasn't meaning to advocate keeping old files around unless there is a good reason. That was just my inspiration to offer an alternate method.

In any case, I do agree that now isn't the time to bother with it, and that it really isn't a big deal.

But, like Jason, I still vote to separate testing.

:-) L

_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Wed Feb 15 2012 - 09:00:02 PST
Custom Search