Improvements to new Windows build scripts
Description
Environment
Activity
Rod Widdowson January 18, 2018 at 4:45 PM
I'm going to close this off.
There is plenty of room for more work but none of it adds function or ease and it basically just "turd polishing".
From the "Todo" list above the only not done thing is buildpath.props. We decided to leave this as is since it does not impact the deliverable in the way that (for instance) the the boost version might so just leave it untagged.
Rod Widdowson December 10, 2017 at 9:59 PM
changes pushed
Rod Widdowson December 10, 2017 at 7:51 PMEdited
Progressing well, final test under way before a massive rebase and push.
Other work needed and which will be done here is:
Kill off buildpaths.props
Kill off all the non VC15 build environments. Leave the tree as is (
Projects/vc15/xyl.sln) so that when things change again we are readyKill of the old batch based build commands
Rod Widdowson December 6, 2017 at 10:15 AM
My concern is that it may be more than a few variables. OTOH a lot of them are only used when building the installers (things like the precise file version name of the various DLLs) so a few would probably be enough for building cpp-xmltooling, cpp-opensaml, cpp-sp.
I'll try to make sure that the "needed to build a DLL" environment variables are clearly distinquished from the "needed to build the installer" ones.
Scott Cantor December 5, 2017 at 2:25 PM
If you mean our code, no, I usually use the IDE, but I could probably just set some variables in my environment globally so the IDE would run.
We need to get the build script(s) as robust as possible to make them foolproof when doing builds on new machines and by somebody not as well-versed in the build.
Some suggestions:
Resolving duplication between Versions.props and the batch files around library versions.
Moving locations and settings that tend to be machine specific like the build root out to a separate included script file or just declaring them "required environment settings" so we can avoid checking in personal settings.
Testing whether some of the settings need to be set or not to allow us to override locations or other values from outside the scripts.
Making sure to cd back to the folder the script was run from so you're not stranded in the dependency's directory on an error.
I also have observed it repeatedly re-running the CMake step for Xerces, which adds a lot of time to repeated runs of the build, that may not be intentional, not sure.