Includes status, proposed strategies. Newest entries are at the top.
March 5, 2009
Accomplished some clarification by adding more information to variant names. SCons variant now incorporates compiler (e.g. instead of redhat4-i686-32bit-Debug on Linux will now get redhat4-i686-32bit-gcc34-Debug; on Windows now get
XP-i386-32bit-vc90-Debug). Project files also include a name called the 'variant'. It now looks just like the SCons variant except it starts with Visual, e.g. Visual-vc90-Debug.
However problems involving directory structure, interactions between SCons builds and Studio builds are looming. The work areas - where intermediates like object files get built - are distinct and probably should remain so. But what about the install area? SCons builds both refer to it when searching for include files or libraries and write to it. If link commands issued by Studio are to be roughly analogous to those used by SCons, it has to do the same thing. In this case, should it use the same install area or a separate one? (I would think the same.) How do I tell Studio to copy libraries to the install area? What about public sources; that is, the files that go in the top-level include, xml, etc., directories?
March 4, 2009
Inching forwards.. Project file produced now can be used by Studio to make a .def file (needed at link time to export everything we want exported) which looks more or less reasonable, though smaller than the one SCons makes with its "native" build. However the prelink command is probably still not quite right. It's using the objects build by SCons as input rather than the objects Studio built. Should be able to fix Have fixed this with more tinkering, but the total amount of tinkering going on is unsettling at best.
...