On Sun, Feb 15, 2009 at 9:19 AM, René Jansen <rvjan...@xs4all.nl> wrote:
René > One final thing, I saw that the test suite now has a platform dependent > path. Could we move the platform dependent stuff to the end, so that the > platform independent suite runs first? I assume you mean the tests for the new native API. If you don't want to run those tests, then use this command line to skip them: testOORexx.rex -X Native_api which says eXclude the tests of type Native_api. I'm pretty sure the keyword is case independent. If you're going to run the tests, it shouldn't make any difference what order the tests are in. Likewise, if you use -X to exclude the tests, it shouldn't make any difference what order the tests are in. <grin> The order of the tests is simply the order of the files found by SysFileTree. API is going to come before any other category of tests that I can foresee. We can change the order by renaming the API directory to some other thing, but I don't see any point to it. If there is some dependency I overlooked in the test framework so that, even when using the -X arg, the rest of the test suite is not running on MacOSX then let me know. It should be fixable. > I am not overwhelmed by this, because > I mostly test on one platform only, and would have thought auto-etcetera > could have crafted the test suite to have the required amount of platform > dependency (which should be limited to build parameters and nothing > further). I'm not 100% sure what you mean here. The native API tests themselves are platform independent. But, the tests require some external binaries to be built. It is the building of these binaries that is, obviously, platform dependent. To tell the truth, my first vision of how this would work did not include constantly re-building the external binaries. I envisioned that after the binaries finished their initial development stage, they would be added to the test framework as static pre-built objects. The code for the external binaries has not changed for several months. What I thought would be done would be that those who had the resources would build the binaries for some platform and the binaries would be checked into the framework and left there. The current system is much more flexible if the source for the external binaries is undergoing changes. But, not so easy for people who do not have the resources to build the external binaries on their platform. > Please do explain what this brings us. What this brought us was the ability to get the tests for the native API quickly up and running for both Linux and Windows. In my opinion this brought us a lot. If you can design and code up a better way to do this, then please feel free to do so. <grin> On the other hand, if you could come up with a make file that builds the external binaries on Mac, I'll integrate it into the framework and help make sure things are working. This is essentially what Rainer did for AIX. -- Mark Miesfeld ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
