I agree. Trying to reproduce all the options in place for the main build in a test build environment will be error prone. And the upkeep for multiple build environments will be worse than a single build environment.
David Ashley On Wed, 2014-10-29 at 11:24 -0400, Rick McGuire wrote: > I've been rethinking how the API test binaries are generated and built > as part of some restructure work on the test framework. My first > thought was to convert the build to use CMake. In the course of > creating the CMake script, there were a number of issues that needed > to be resolved, such as where the libraries and include files were > located, where to generate the CMake output, issues with having to > constantly switch between 32- and 64- bit builds, what platforms are > supported, etc. > > > I'm starting to think that the easiest solution to this would be to > move the test sources into the main development tree, then generate > the test binaries as part of the build. This eliminates a lot of the > build issues, and also ensures that the tests will be picking up > binaries that match the interpreter version being tested. > > > This is really pretty trivial to do. The binaries will be built into > the normal output directory, but will not be included as part of the > install. I'm really thinking there are some big wins here. Does > anybody see any downsides with doing this? > > > Rick > ------------------------------------------------------------------------------ > _______________________________________________ > Oorexx-devel mailing list > Oorexx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/oorexx-devel ------------------------------------------------------------------------------ _______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
