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
