I like the idea of generating the files in a separate process. That way it keeps the CMake build clean and straightforward.
Oh, and the Linux version of the script to generate the files using Xalan is really simple so no problem there. David Ashley On Fri, 2014-05-02 at 06:31 -0400, Rick McGuire wrote: > David, > > > I saw your check in comment about disabling the XSL generation and I > understand the problem. I spent some time googling for best practices > for generated code with cmake (a common problem, it appears), and all > of the solutions end up generating the files into the build directory > and using them from there. So, assuming that is what is needed, let's > explore the options. > > > One option you stated was to drop the generation completely. That one > is a non-starter. The number of things that need to get updated when > either of the XML source files changes would lead to lots of problems > and be terrible error prone. Since 99% of the time I'm the one doing > the update, I'm the one most impacted by the tedium and errors > involved. That's why I went to generated files in the first place. > > > Your second option is to remove the generated files from SVN and > always generate the files as part of the build and use the ones from > build directory for the build. This will work, but I'm not terribly > happy with adding the additional tool requirement to the build, plus > based on what I've read about generated files, there are some tricky > problems involved with doing this. This is a workable solution, but I > think I have a better idea. > > > These files change fairly rarely, and 99% of the time, I'm the one > changing them. I don't see much problem with not having the update of > these files be a separate manual step rather than part of the > makefile. The build will use the versions in SVN, but will not worry > about generating the new files when the XML files change. Then we'll > write a separate build utility that will update the source tree if we > need to and then check the changed files back into the tree once > everything is verified. This utility can be a simple as a windows > batch file containing the Xalan commands we currently use. Maybe > someone could write a shell script version of this as well, but again, > for 99% of the updates, the Windows batch file will work because I > suspect I'm likely to be the only one doing these updates. > > > We could also drive this from cmake, having the files get generated > into a location in the build directory, then have a wrapper script > that copies them back into the source tree. The cmake solution would > be done by having a separate build target that has to be explicitly > invoked and is not a dependency of the main build. This would still > be a manual step and only a developer doing work that requires the > update would need Xalan for this. > > > Rick > ------------------------------------------------------------------------------ > "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE > Instantly run your Selenium tests across 300+ browser/OS combos. Get > unparalleled scalability from the best Selenium testing platform available. > Simple to use. Nothing to install. Get started now for free." > http://p.sf.net/sfu/SauceLabs > _______________________________________________ > Oorexx-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/oorexx-devel ------------------------------------------------------------------------------ "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs _______________________________________________ Oorexx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oorexx-devel
