I don't see one. Probably should have some entry in the "building" area
that describes their use.
On Jul 12, 2012, at 12:30 PM, Nathan Hjelm wrote:
> I wouln't consider sourced variables being overritten by the sourcing
> platform file a problem. I can update the platform file documentation t
I wouln't consider sourced variables being overritten by the sourcing platform
file a problem. I can update the platform file documentation to make sure this
behavior is clear. Can you point me at the right faq page?
-Nathan
On Mon, Jul 09, 2012 at 08:36:41PM -0700, Ralph Castain wrote:
> Okay,
Okay, it took me awhile to grok thru all this, and I now understand how it is
working. You do have a question, though, with duplicated entries. At the
moment, we ignore any entry that is duplicated on the configure cmd line -
i.e., if you set something in a platform file, and then attempt to als
I keep scratching my head over this, and I just cannot figure out how this is
going to do what you think. We "source" the platform file solely to execute any
envar settings that are in it - i.e., to capture the CFLAGS=... and other such
directives. We then read/parse the platform file to get all
This is what was missing from your RFC - a simple explanation other than a
one-line "How" or "Why". I know it takes five minutes to be more descriptive,
but you've been getting awfully terse lately with these proposals.
Now that you have explained it, I have no objections.
On Jul 9, 2012, at 3
On Mon, Jul 09, 2012 at 03:31:33PM -0700, Ralph Castain wrote:
> So if I understand this right, you would have multiple platform files, each
> "sourcing" a common one that contains the base directives? It sounds to me
> like you need more than the change below to make that work - you would need
So if I understand this right, you would have multiple platform files, each
"sourcing" a common one that contains the base directives? It sounds to me like
you need more than the change below to make that work - you would need to
interpret the platform file itself to read and execute a "source"
LANL's platform file's (for a particular platform) are 90% the same. By
allowing a source directive those settings can be kept in a common file then
sourced by the platform file. When something changes I wouldn't have to change
a dozen files only a couple.
-Nathan
On Mon, Jul 09, 2012 at 02:21
I'm confused - how does this help maintain a platform file???
On Jul 9, 2012, at 2:09 PM, Nathan Hjelm wrote:
> When: Thurs, Jul 12, 5 PM MDT
>
> Why: Useful feature. Enabling source may cut down on the maintenance required
> to keep platform files up to date.
>
> How: Change directories to t
When: Thurs, Jul 12, 5 PM MDT
Why: Useful feature. Enabling source may cut down on the maintenance required
to keep platform files up to date.
How: Change directories to the platform file's directory before sourcing it
(not after).
diff --git a/config/ompi_load_platform.m4 b/config/ompi_load_p
10 matches
Mail list logo
