Hello ohcount developers,
I forked ohcount at GitHub's to add support for building from MSYS and using CMake. I applied both patches from Tickets 55 and Ticket 56 and included an initial
CMakeFiles.txt config file for the project.
The binary ohcount is already being compiled fine, but there is no support yet for running the tests automatically at the end of the build, and the ruby build has not been tested yet (I am installing Ruby to test it).
My plan is to extend the code to provide a Python module to be reused from Python scripts.
The GitHub's link is http://github.com/balena/ohcount.
Guilherme Balena Versiani.
Thanks for helping with ohcount.
It looks like you made a couple other small improvements along with the changes for MSYS/Cygwin. I'll take a look at these this week and pull if that's okay with you.
Yes, I am improving the CMake build support and the Python binding. I need Python binding for the project XRay located at SourceForge.
The idea here is to use ohcount as the main engine of XRay for loc analysis of several SCMs at once, in a similar way Ohloh does, but by using a single command-line tool.
Just a status of my ohcount fork using CMakeLists.txt:
ohcount command line executable is compiling and working now (passing on tests) using MinGW/MSYS using CMake 2.8.0 and the generator 'MSYS Makefiles'
ohcount extension for Ruby and Python does compile in MinGW/MSYS if you compile Ruby and Python by hand for MinGW/MSYS too (i.e. you don't got Ruby and Python pre-compiled from Ruby and Python websites)
ohcount extension for Ruby and Python does compile in Linux and should compile in other UNIXes as well (not tested for other UNIXes)
ohcount Python binding needs more refinements to simplify usage
Updating my status:
Thanks again Balena,
I pulled your changes to make Ohcount work on Gentoo (use stat) and the WIN32 definition of mkstemp.
The CMake/Python changes need unit tests before I could pull them. If someone else could also test/verify them before pulling that'd be great, otherwise I'll have to carve out some time myself to do so.
I finished to create unit tests for the python binding right now, and I integrated everything in CMakeLists.txt.
I've noted that the Ruby unit test is not passing (please check). For some reason, the element 'first' of the object LocDeltaList is Null in test file
source_file_test.rb. Here is the output generated from CMake testing unit (issue 'cmake -P test/RubyTest.cmake' from the build directory):
Loaded suite ruby_test Started....................................................E. Finished in 1.518952 seconds. 1) Error: test_empty_diff(SourceFileTest): NoMethodError: undefined method `language' for nil:NilClass ./source_file_test.rb:23:in `test_empty_diff' 79 tests, 159 assertions, 0 failures, 1 errors
Fixed other incompatibility with Windows. When you are fopen'ing the files, you forgot (or it was by 'design'?) to pass the flag 'rb', so when there are character conversions (due to the presence of CRLF in Windows source files) the calls to fread does not return the "full size" of the file, and all your functions behave badly (eating errors) as if the system could not read the file at all and settings the file contents to NULL (the result is that all calculations of LOC is zero).
Updated the README file to include CMake documentation. The README didn't contain references to the required tool gperf (I've noted that when I was writing the CMakeLists.txt), so I updated it too.
The Python tests are passing on Windows (MinGW/MSYS), so I am confident that this extension is working as fine as the Ruby extension.
ohcount_unittest.exe is still not passing 100% on Windows yet. I am investigating where are the issues. For now what I can say is that all the results are very close to Linux ones, and I think the differences should only be related to some design options of the source code (it wasn't written thinking to be compatible with Windows as stated somewhere in Ohcount project at SourceForge).
I tried out the CMake build system and it works great on my Linux box.
Andy, any update on getting this into the main repository?
I personally like CMake (it seems faster and less complicated than automake) but it's a new dependency for the build system. But if I saw a few more +1s for it, I'd likely be swayed.
Just a suggestion...
I think the right choice when thinking in dependencies for your project is not to reduce them, but to depend on the right things.
CMake is supported by KitWare and very used around the world. KDE is using it...
Every GNU project depend at least on a 'make'-like program (some people deliver code to compile its own code, but I think it excessive). Some depend on Automake and Autoconf, Ant, Scons, and so on... It is really not a problem.
You can study a way to maintain both compile methods for a while, until the old users and developers understand how to use the new one.
Copyright © 2013 Black Duck Software, Inc. and its contributors, Some Rights Reserved. Unless otherwise marked, this work is licensed under a Creative Commons Attribution 3.0 Unported License . Ohloh ® and the Ohloh logo are trademarks of Black Duck Software, Inc. in the United States and/or other jurisdictions. All other trademarks are the property of their respective holders.