<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html><head><meta content="text/html;charset=UTF-8" http-equiv="Content-Type"></head><body ><div style='font-size:10pt;font-family:Verdana,Arial,Helvetica,sans-serif;'><div>Hi Igor.<br></div><div><br></div><div>I am not experienced enough in make/build systems to have an opinion.</div><div><br></div><div>I notice it is only on Unix configurations that implement the configH method.</div><div><br></div><div>I do note, that I did have to modify it to get the UUIDPlugin to compile on my system. </div><div><br></div><div>This is not a big deal at all as editing that method is just another step in setting up a Configuration.</div><div><br></div><div>I am documenting this in the Help for the package. I will try (once I am fluent in the system and it works like a machine) to create a step-by-step instructions for building a new configuration.</div><div>Modifying that configH method will be one of those steps.</div><div><br></div><div><br></div><div>I was thinking last night that a possible addition to the system would be to create a CMakeVMMaker plugin configuration wrapper that would store the configuration state for a configuration for a plugin.</div><div>Then, on your CMakePluginGenerator, access the configuration method on that wrapper and have it inject its information into the config.h.</div><div><br></div><div><br></div><div>That is a BIG task that will take a lot of brain cycles that I don't want to spend until after I deliver the first release.<br></div><div><br></div><div>Say we have Concrete configuration for build.linux32x86.squeak.cog.spur/build &nbsp;(&lt;--Eliot's organization principle, not to be confused with Heisenberg's uncertainty principle...)</div><div><br></div><div>In CMakeVMMakerSqueak, this maps to concrete configuration class Linux32x86SqueakCogSpurConfig that is configured for build type:#build</div><div><br></div><div>Have a parallel PluginWrapper class Linux32x86SqueakCogSpurPluginConfig configured for type:#build.</div><div><br></div><div>Then in CMakePluginGenerator generate do the following:</div><div><br></div><div>&nbsp; &nbsp; modify it to access the plugin via the wrapper class instead of directly</div><div>&nbsp; &nbsp; carry a config.h WriteStream in CMakeVMGenerator to eventually write out the config.h file</div><div>&nbsp; &nbsp; add a method to have the Plugin Wrapper inject its content into that write stream.</div><div>&nbsp; &nbsp; &nbsp;write out config.h at same time as build.sh and CMakeLists.txt in&nbsp;</div><div><br></div><div>That is several days of work--probably a week.</div><div><br></div><div>I think it makes more sense for now to just modify the configH method directly in the limited number of concrete configurations that need it.</div><div><br></div><div>cheers.</div><div><br></div><div>tty</div><div><br></div><div><br></div></div></body></html>