<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? > > -Nathan > > 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. >>>> >>>> -Nathan >>>> _______________________________________________ >>>> devel mailing list >>>> de...@open-mpi.org >>>> http://www.open-mpi.org/mailman/listinfo.cgi/devel >>> >> >> >> _______________________________________________ >> devel mailing list >> de...@open-mpi.org >> http://www.open-mpi.org/mailman/listinfo.cgi/devel > _______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel
