Hi Dr. Mike (1), I like your work. For starters we can create branch on the git repository and see how it plays out. It is true that the compile time switches are slightly messed up. I am seriously thinking to add autoconf support; that might help for porting, but is also adds an unnecessary complexity.
The easiest way to interact with my git repository is to create a github account and "fork" the repository. Then commit to your "fork" and I can pull the changes into my local repository, see if they work and merge them into the mainline. Then I upload the changes to the public repository. Of course you can create any public repository anywhere and I can pull from that. Finally I would also take patches generated with git-format-patch; though I prefer the public git repository solution, since it makes followup pulls more straight forward. Sean (1) I added it since it sounds cool... On Tue, Feb 2, 2010 at 1:25 PM, Clark Gaebel <cg.wowus...@gmail.com> wrote: > Fork the github repository and send a pull request. > > http://github.com/rioki/unittest-cpp > > On 01/02/2010 11:07 PM, Mike Smith wrote: >> I have prepared a patch to demonstrate the code needed to handle >> UnitTest++ for an embedded system -- Analog Devices BF533 specifically. >> >> Given that this appears to be the first patch related to an embedded >> system, I am more than willing to rework the patch so that it is easy to >> upload other embedded patches in a consistent format without making the >> whole system fall apart >> >> Basically I have a directory EmbeddedUnitTest++ under UnitTestst++ where >> there are processor specific files associated with a project to build >> the library and a project to build the tests of the library. That >> separates the embedded projects from the windows projects in a pretty >> generic manner. >> >> Under the UnitTest++/src directory -- you have to modify the >> "Timehelpers.h" to redirect the compiler to use the appropriate helper file >> That I don't like as a format as that could get very clumsy as the >> number of processors increases >> >> Have added ADI_Helpers (Analog Devices Inc) for Blackfin and TigerSHARC. >> Have also got a Generic_Helpers subdirectory so that others can see the >> necessary format. *For consistency, it would be useful for the Win32 >> directory for helpers be renamed Win32_Helpers.* >> >> I can't always load all the tests into memory and have to load a couple >> of files at a time. I would appreciate seeing TestCheckMacros.cpp to be >> broken up into a number of smaller files (even TestCheckMacros1.cpp, 2 >> and 3) as it is very large compared to the object file size of all the >> other test files.. This was an unexpected a loader issue -- I think I >> can modify the ldf of the processor (loader description file) to make it >> happy to load in this file as a whole, but it might not be a possibility >> with other embedded systems. >> >> In the test directory, there are a couple of files that have tests that >> need excluding (a.k.a ifndef UNITTEST_MINGW in TestTest.cpp) >> Not good on double negatives -- would the syntax be >> >> #if ! ( defined(UNITTEST_MINGW) | defined(__ADSPBF533__) ) >> >> The UnitTest test files uncovered a compiler issue on one of the >> processors, which is currently being patched. The problem was >> essentially the following -- The compiler generates annotations about >> how the code format needs to be fixed to make efficient code. Apparently >> the total number of inefficiencies recognized in the test code exceeded >> the depth of "something" in the annotations generator ;-) >> >> Also, once placed in an acceptably format, how / where do I upload the >> suggested patch >> >> Thanks >> >> Mike >> >> Michael Smith Ph. D., >> Professor, Department of Electrical and Computer Engineering. >> Adjunct Professor, Department of Radiology, University of Calgary. >> Analog Devices University Ambassador. >> >> Electrical and Computer Engineering, Voice: (+1) 403-220-6142 >> University of Calgary, Calgary, Fax: (+1) 403-282-6855 >> Alberta, Canada T2N1N4 Email: mike.sm...@ucalgary.ca >> >> Experience can't be taught, experience can only be earned. >> >> >> ------------------------------------------------------------------------------ >> The Planet: dedicated and managed hosting, cloud storage, colocation >> Stay online with enterprise data centers and the best network in the business >> Choose flexible plans and management services without long-term contracts >> Personal 24x7 support from experience hosting pros just a phone call away. >> http://p.sf.net/sfu/theplanet-com >> _______________________________________________ >> unittest-cpp-devel mailing list >> unittest-cpp-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/unittest-cpp-devel > > ------------------------------------------------------------------------------ > The Planet: dedicated and managed hosting, cloud storage, colocation > Stay online with enterprise data centers and the best network in the business > Choose flexible plans and management services without long-term contracts > Personal 24x7 support from experience hosting pros just a phone call away. > http://p.sf.net/sfu/theplanet-com > _______________________________________________ > unittest-cpp-devel mailing list > unittest-cpp-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/unittest-cpp-devel > ------------------------------------------------------------------------------ The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com _______________________________________________ unittest-cpp-devel mailing list unittest-cpp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/unittest-cpp-devel
