<br><font size=2 face="sans-serif">Please move this discussion of the dcmf
build system to the mailing list.</font>
<br>
<br><font size=2 face="sans-serif">Thanks!</font>
<br>
<br><font size=2 face="sans-serif">Michael Blocksome<br>
Blue Gene Messaging Team Lead<br>
Advanced Systems SW Development<br>
blocksom@us.ibm.com<br>
</font>
<br><font size=1 color=#800080 face="sans-serif">----- Forwarded by Michael
Blocksome/Rochester/IBM on 02/06/2008 09:04 AM -----</font>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>Sameer Kumar/Watson/IBM</b></font>
<p><font size=1 face="sans-serif">02/05/2008 10:52 PM</font>
<td width=59%>
<table width=100%>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td><font size=1 face="sans-serif">Pavan Balaji &lt;balaji@mcs.anl.gov&gt;</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td><font size=1 face="sans-serif">Darius Buntinas &lt;buntinas@mcs.anl.gov&gt;,
Dave Goodell &lt;goodell@mcs.anl.gov&gt;, Rajeev Thakur &lt;thakur@mcs.anl.gov&gt;,
William Gropp &lt;wgropp@uiuc.edu&gt;, Ahmad Faraj/Rochester/IBM@IBMUS,
Bob Cernohous/Rochester/IBM@IBMUS, Brian Smith/Rochester/IBM@IBMUS, buntinas@mcs.anl.gov,
Craig Stunkel/Watson/IBM@IBMUS, Douglas Miller/Rochester/IBM@IBMUS, Gabor
Dozsa/Watson/IBM@IBMUS, Jeff Parker/Rochester/IBM@IBMUS, Joseph Ratterman/Rochester/IBM@IBMUS,
Michael Blocksome/Rochester/IBM@IBMUS, Robert Wisniewski/Watson/IBM@IBMUS</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td><font size=1 face="sans-serif">Re: MPICH2 threading results</font><a href=Notes://D27mc103/062565D400635E43/A24CF79FA927570285256356005827C4/DFD8DFAE93D5970A852573E60077327A>Link</a></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br><font size=2 face="sans-serif">Hi Pavan,</font>
<br>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Thanks
for checking with us. &nbsp;Here are some comments : </font>
<br>
<br><font size=2 face="sans-serif">1) &nbsp;The top level comm/Make can
build both dcmf &nbsp;(including ccmi the collective library) &nbsp;and
MPICH. &nbsp;May be the configure (at the top level and in mpich) scripts
can pass options to that Makefile? &nbsp;</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; At
research we use a slightly differnt way of compiling messaging stack. &nbsp;If
you cd to comm/sys/messaging you will find a configure and Makefile.in
which builds the messaging dir. &nbsp;You can run configure at the comm/sys/messaging
(collectives) levels too. &nbsp;It can also take options (--with-rootdir=/.../)
to where the bgp/ (arch and runtime dirs) are installed. &nbsp;I just thought
I will let you know. </font>
<br>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; The
sub-directory sys/ represents a set of system components including messaging,
collectives, sysdeps (in messaging) etc. The other directory libs has higher
level programming languages which arent system dependent. &nbsp;The names
of the directories predate dcmf and so there are also historical.</font>
<br>
<br><font size=2 face="sans-serif">2) &nbsp;The arch directory mainly has
a set of include files shared between the kernel (cnk) and messaging and
other components. &nbsp;In the main repository, there is bgp at the top,
bgp/arch bgp/cnk, bgp/runtime, bgp/comm and others below it. &nbsp;So it
may be a good idea to leave arch in a seperate repository and postponing
this decision till the kernel is open-sourced.</font>
<br>
<br><font size=2 face="sans-serif">3) &nbsp;Supporting both options and
env vars would be good as different researchers/developers may prefer one
over the other.</font>
<br>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; sameer.</font>
<br>
<br>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>Pavan Balaji &lt;balaji@mcs.anl.gov&gt;</b>
</font>
<p><font size=1 face="sans-serif">02/05/2008 04:27 PM</font>
<td width=59%>
<table width=100%>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td><font size=1 face="sans-serif">Sameer Kumar/Watson/IBM@IBMUS</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td><font size=1 face="sans-serif">Darius Buntinas &lt;buntinas@mcs.anl.gov&gt;,
Dave Goodell &lt;goodell@mcs.anl.gov&gt;, Rajeev Thakur &lt;thakur@mcs.anl.gov&gt;,
William Gropp &lt;wgropp@uiuc.edu&gt;, Joseph Ratterman/Rochester/IBM@IBMUS</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td><font size=1 face="sans-serif">Re: MPICH2 threading results</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><tt><font size=2>Sameer,<br>
<br>
&gt; 3) &nbsp;Git patch for a new configure<br>
<br>
Will you be willing to accept a patch to separate out mpich2, dcmf and
<br>
the rest of the code with independent configures? Separating out MPICH2
<br>
alone won't make much of a difference if we have to clone the entire <br>
repository anyway every time we want to try an alternate version of DCMF.<br>
<br>
Here's my thought. You can confirm whether this would be acceptable to
<br>
you guys:<br>
<br>
1. Add a separate configure or Makefile in the sys directory which will
<br>
allow us to treat it as a separate and independent package. Btw, just <br>
out of curiosity, is there a reason this directory is called &quot;sys&quot;
<br>
instead of &quot;dcmf&quot;?<br>
<br>
2. Include the arch directory into the sys directory (as suggested by Kaz).<br>
<br>
3. Add a separate configure for MPICH2 to accept the path to the DCMF <br>
package we want to use (--with-dcmf=&lt;path_to_dcmf&gt;).<br>
<br>
For the third point, there is already an option to pass this information
<br>
in through environment variables. However, changing the environment <br>
variable does not modify the DCMF path at runtime. That is, the <br>
environment variables are only used at configure time. So, is this just
<br>
a matter of preference or is there a reason to do this? Either way, we
<br>
can just leave it in there. There's no strong reason to change it.<br>
<br>
Thanks.<br>
<br>
 &nbsp;-- Pavan<br>
<br>
-- <br>
Pavan Balaji<br>
http://www.mcs.anl.gov/~balaji<br>
</font></tt>
<br>