Hi Michael,<br><br>Thanks for the comments. I have implemented all of the changes you described, and attached a new version.<br><br>Also, the list of available cores is auto populated by grabbing any directory with core_ in it's name from the src/ directory. So if new cores are added (or removed) the makefile doesn't need to be modified to show them.<br>
<br>Let me know if there are any other comments. Otherwise I'll commit it probably by the end of the day today.<br><br>Doug<br><br><div class="gmail_quote">On Mon, Feb 27, 2012 at 11:18 AM, Michael Duda <span dir="ltr"><<a href="mailto:duda@ucar.edu" target="_blank">duda@ucar.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi, Doug.<br>
<br>
This looks really good. I have just a couple of minor comments.<br>
<br>
In the usage text, I'm not sure if the term "compile groups" will be<br>
familiar to most people; perhaps something like "target" instead, like:<br>
<br>
Example targets:<br>
ifort<br>
gfortran<br>
xlf<br>
pgi<br>
<br>
It might be simpler if we omit the "core_" text altogether in<br>
<br>
Availabe Cores: (without core_)<br>
core_atmos_physics<br>
core_hyd_atmos<br>
core_init_nhyd_atmos<br>
core_nhyd_atmos<br>
core_ocean<br>
core_sw<br>
<br>
so that it just reads<br>
<br>
Availabe Cores:<br>
atmos_physics<br>
hyd_atmos<br>
init_nhyd_atmos<br>
nhyd_atmos<br>
ocean<br>
sw<br>
<br>
Also, I think it would be better to use absolute paths for libraries, rather<br>
than relative paths, so the last bit of text would read<br>
<br>
Ensure that NETCDF (and PAPI if USE_PAPI=true) are environment variables<br>
that point to the absolute paths for the libraries.<br>
<br>
<br>
For error checking, would it also be possible to catch the case where no<br>
make target is specified? I typically just set the environment variable CORE<br>
and usually run something like "make pgi", but if I type just "make", the<br>
build fails quickly with no clear error message; could we add something to<br>
catch this?<br>
<br>
Overall, I think these changes will make our lives much easier!<br>
<span><font color="#888888"><br>
Michael<br>
</font></span><div><div><br>
<br>
On Mon, Feb 27, 2012 at 09:29:04AM -0700, Doug Jacobsen wrote:<br>
> The only two compiler groups that are "set up" are ifort and gfortran, at<br>
> least for debug options. But we would need to come up with debug flags for<br>
> each of the compilers so the DEBUG=true would work.<br>
><br>
> SERIAL=true and USE_PAPI=true are not related to the compiler groups<br>
> though, as long as the FC_SERIAL and CC_SERIAL compilers are set properly.<br>
><br>
> Doug<br>
><br>
> On Mon, Feb 27, 2012 at 8:11 AM, Mark Petersen <<a href="mailto:mpetersen@lanl.gov" target="_blank">mpetersen@lanl.gov</a>> wrote:<br>
><br>
> > Doug,<br>
> ><br>
> > This looks great. I appreciate the general formulation, so that flag<br>
> > preferences for each compiler type can be kept in the makefile.<br>
> ><br>
> > Mark<br>
> ><br>
> ><br>
> > On 02/25/12 12:06, Doug Jacobsen wrote:<br>
> ><br>
> > Hi All,<br>
> ><br>
> > In the ocean development group, we have been discussing making options in<br>
> > the makefile for debug builds. So, I have attached a proposed revision to<br>
> > the current makefile structure, in order to make debug, and other modified<br>
> > builds, easier to maintain.<br>
> ><br>
> > If you call make incorrectly (without CORE= or a compiler set) you will<br>
> > get a usage statement now. I collapsed all of the compiler sets<br>
> > (ifort-serial ifort-serial-papi ifort-papi ifort) into one master set<br>
> > (ifort). My thoughts here were that it would be easier to maintain a single<br>
> > set of flags for a compiler than one for each potential version of the<br>
> > compiler. I also added three "options" to the make process. Which are as<br>
> > follows.<br>
> ><br>
> > DEBUG=true - Builds a debug version of the code, the default is the<br>
> > optimized build.<br>
> > SERIAL=true - Builds a serial (non-MPI) version of the code, the default<br>
> > is to build the parallel (MPI) version of the code.<br>
> > USE_PAPI=true - Builds a version of MPAS using the PAPI library for timers<br>
> > and hardware counters. The default is to not use this.<br>
> ><br>
> > These can all be appended to make along with the CORE=core option. So, an<br>
> > example to build a serial debug version of MPAS that uses PAPI libraries<br>
> > would be<br>
> > "make gfortran CORE=ocean DEBUG=true SERIAL=true USE_PAPI=true"<br>
> ><br>
> > Any values for DEBUG, SERIAL, and USE_PAPI that are not "true" invoke the<br>
> > default options for those.<br>
> ><br>
> > Please take a look at the attached makefile, and let me know if anyone has<br>
> > any comments or questions about it. I would like to push this onto the<br>
> > trunk early next week if possible.<br>
> ><br>
> > Thanks,<br>
> > Doug<br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > mpas-developers mailing listmpas-developers@mailman.ucar.eduhttp://<a href="http://mailman.ucar.edu/mailman/listinfo/mpas-developers" target="_blank">mailman.ucar.edu/mailman/listinfo/mpas-developers</a><br>
> ><br>
> ><br>
<br>
> _______________________________________________<br>
> mpas-developers mailing list<br>
> <a href="mailto:mpas-developers@mailman.ucar.edu" target="_blank">mpas-developers@mailman.ucar.edu</a><br>
> <a href="http://mailman.ucar.edu/mailman/listinfo/mpas-developers" target="_blank">http://mailman.ucar.edu/mailman/listinfo/mpas-developers</a><br>
<br>
</div></div></blockquote></div><br>