| Summary: | "features" cannot be used to turn on/off specific features in CDT6 via global.mpb | ||
|---|---|---|---|
| Product: | MPC | Reporter: | Chris Cleeland <cleeland_c> |
| Component: | MPC | Assignee: | Chris Cleeland <cleeland_c> |
| Status: | NEW --- | ||
| Severity: | normal | ||
| Priority: | P3 | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| Attachments: | Hack fix | ||
engaged Chad's help on this and he got the same results on mosquito that I was getting, so we remove personal environment issues, and postulated that debugging would take one down the path of debugging where global.mpb gets read to see if there's a difference (begin by debugging inside ProjectCreator::read_global_configuration() ). While I was doing that, apparently Chad did a little further investigating on his own and sent me this: > I have figured out that it has something to do with the other > projects that are not written (due to requires) and the order in > which they are processed. > > As a test, make the following workspace: > > workspace { > ace.mpc > ace_xtreactor.mpc > } > > Process this, and you will get the correct results. > > Use the following workspace and you will get incorrect results > (regardless of the machine): > > workspace { > ace_xtreactor.mpc > ace.mpc > } > > Good luck on debugging this one. :-) > > Actually, I'm guessing that it has to do with the 'addtemp' hash > variable in the Creator/ProjectCreator self being cleared out at the > end of a project. I think this is the first time global.mpb ever > contained a feature project and the values are being stored in the > per-project template variable storage. So, after the first project > it gets wiped out. I guess processing a feature project while > reading the global configuration should cause those feature project > attributes to be stored in a hash map that is persistent for the > life of the ProjectCreator object. > > Chad Consequently, this looks like a bug in MPC, not a bug in the CDT templates. In this particular case, we've found a workaround by setting "use_threads=1" in the template using the -value_template command-line option, e.g., mwc.pl -type cdt6 -value_template use_threads=1 [...etc...] That may not seem like a big deal, but the same technique used for threads is going to be used for other compile-time platform-dependent options in ACE, e.g., Asynch IO presence, so those setting would also have to be specified on the command line which will quickly get unwieldy. It also means that one can't provide settings for these in default.features. Created attachment 1308 [details]
Hack fix
This is a one-line hack that eliminate the bug, but introduces a performance issue during MPC generation. At least it demonstrates the problem.
|
This was discovered during implementation of the CDT6 work, but it could apply to any project type. CDT6 has the following setup: ACE's acedefaults.mpb: feature(!threads) { specific(cdt6) { macros += ACE_MT_SAFE=0 // and without threads we must remove support for AIO. macros -= ACE_HAS_AIO_CALLS platform_libs -= rt } } MPC's global.mpb: feature(threads) { specific(cdt6) { use_threads = 1 } } MPC's cdt6cproject.mpd: ... <%foreach(platform)%> ... <option id="mpc.generated.linkflags.1" superClass="< %linker_option_superclass%>\ .flags" value="<%if(use_threads)%> <%threadflags%><%endif%>< %if(linkflags)%> <%\ linkflags%><%endif%><%if(build64bit && linkflags64)%> <%linkflags64%>< %endif%>"\ valueType="string"/> ... <%endfor%> ... MPC's cdt6platforms.mpt: linux { binary_parsers = org.eclipse.cdt.core.ELF error_parsers = org.eclipse.cdt.core.GASErrorParser org.eclipse.cdt.core.GLDE\ rrorParser org.eclipse.cdt.core.GCCErrorParser threadflags = -pthread platform_libs += rt dl } However, when I generate projects using mwc.pl -type cdt6 - value_template platforms="linux blah" neither "-pthread" nor "- DACE_MT_SAFE=0" show up as compiler options, and I can't figure out why.