<laugh> 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 to make sure this behavior is clear. Can you point me at the right faq page?
> On Mon, Jul 09, 2012 at 08:36:41PM -0700, Ralph Castain wrote:
>> 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 also set it on the cmd line, we ignore the cmd line (without warning). In this case, an entry in the first file that is duplicated in the second file gets overwritten, also without warning.
>> Dunno if that's an issue or not, but something to be aware of.
>> On Jul 9, 2012, at 4:52 PM, Ralph Castain wrote:
>>> 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 the configure directives - e.g., enable_debug=yes. Sourcing the platform file will set the envars, but won't capture the rest of the directives.
>>> Am I missing something here? It doesn't sound like you've really even tried this yet - sure, chaining "source" commands will work, but do you actually get the desired configuration??
>>> Hence my comment about needing to modify the parser so it ALSO follows the "source" directive.
>>> On Jul 9, 2012, at 3:58 PM, Nathan Hjelm wrote:
>>>> 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 to interpret the platform file itself to read and execute a "source" directive inside it, wouldn't you?
>>>> That is exactly what I want to do. The change in the RFC is the only one needed as platform files are sourced by ompi_load_platform.m4. This means platforms can contain arbitrary m4/shell code (including the source directive)! I tried my patch with a one line platform file that sourced an existing platform file and it worked as expected.
>>>>> It would really help if your change (either comments or the RFC) actually explained what the heck you are doing so I wouldn't have to waste hours trying to figure out the impact of this patch :-/
>>>> The RFC does explain what the patch does but I guess I could have elaborated on the implications.
>>>> Before the patch we source the platform file then cd into the platform directory to find the mca parameters file. If a platform file were to have a source directive then it would have to be relative to the build directory (or absolute). By cding into the platform file's directory before sourcing the platform file and source directives are relative to the platform file's directory (or absolute). There is no impact outside of m4/shell commands within the platform file that read/write/stat files.
>>>> I will add some additional comments before the commit (if there are no objects of course) elaborating on the change.
>>>> devel mailing list
>> devel mailing list
> devel mailing list