Forums : The Ohcount Project

Hello Ohcount developers,

I've finished to do some cherry-picking of my development code to help you in testing and pushing the code to 'master' at Github.

For both branches mentioned below, I applied the MinGW/MSYS patches you've already pushed to 'master' and another patch I made to solve some final issues related to file reading on Windows (you were passing just the flag 'r' for fopen() calls, and you know, Windows have that CRLF conversion headaches; I've just completed the flag with a 'b' for binary reading).

I think you can start to remove the lack of Windows support from your documents. We are very close to have an identical behavior on MinGW/MSYS than you have on Linux. Indeed, by running some high-end tests on the code, I obtained the same values, but for some non-obvious reason your unit tests are not fully passing yet...

CMake support (and MinGW/MSYS compiling)

The branch 'cmake_only' can be applied if you want to integrate just the CMake building support (there is no Python extension there). You can test both the command-line tool and the ruby extension by using CMake (everything is finished and tested, besides two tests of the Ruby were not passing, but as I didn't change anything in Ruby code, I believe that this was the state of the code when I forked). To test CMake building, use this:

cd ohcount
mkdir cmake-build && cd cmake-build
cmake .. # for MSYS, just add -G 'MinGW Makefiles'
make
make test # this will run your unit tests

If somebody asks for how to disable Ruby extension, you can answer like this (the Python extension can be enabled like this too if you are using the 'master' branch):

cd ohcount
mkdir cmake-build && cd cmake-build
cmake -DENABLE_RUBY=FALSE ..
make
make test

Someone can ask to use CMake to build a good 'install' command, but since the original 'build' script didn't do so, I didn't bother to make it now... Maybe next time.

Some CMake caveats

• You could get error messages if you are not using CMake version 2.8, so pay attention here.

• When using MSYS, you can get an error message like 'PCRE library not found, you need it in order to build ohcount' or something related to the lack of a Microsoft compiler; in this case you forgot to pass -G 'MinGW Makefiles' option to CMake (check the steps above).

Python support

The branch 'python_only' can be applied if you want to test only the Python 'extension layer' for Ohcount. I didn't touch anything in the original building process here. I included a small unit test (indeed it seems to be a 'smoke test' at all) for the Python code. You are able to build Ohcount extension by executing the traditional commands:

python setup.py build
python setup.py install

CMake and Python support

And finally, if you want to check both codes integrated (CMake and Python), you just use the 'master' branch.

I hope to have contributed to something and simplified your job...

Regards,

-Balena.

Guilherme Balen... over 14 years ago

Wow. Sounds thorough and thoughtful. I'll take a look tomorrow Pacific time.

Thanks Balena.

Andy Verprauskus over 14 years ago

Hey Balena,

I've integrated the python changes with a couple trivial changes.

The CMake build seems to work but I don't want to have two competing build systems in the master trunk. So before we take CMake, I'd like comments from others that it works on their platform, i.e. CMake works for me on MacOS, CMake works for me with this change on ubuntu, etc.

So if you're reading this thread and have tried the ohcount cmake build Balena wrote or have other thoughts about switching to Cmake as our build system please let us know. Thanks!

Andy Verprauskus over 14 years ago

Hello Andy,

Regarding the move of 'setup.py' to 'python/setup.py', I have just one consideration: the presence of this file in the directory 'python' means that 'setup.py' file will be distributed in the ohcount Python extension install dir (it will appear in '/site-packages/ohcount/setup.py')... Yes, there is a way to remove it from the install step, but... Are this really necessary?

Another thing: the 'default' behavior for any Python extension is to have a setup.py in the root directory of the distribution (and that is the normal thinking of every Python user). Just think about it, and if you really feel that it sounds good for you all to have this script in 'python/setup.py' I will make more changes to it to accomplish the requirement to not be installed together with Python ohcount extension.

Regarding the CMake support I agree with you, and you must be comfortable with this building system in advance to change. What I can tell you is that this build works like a charm for MinGW/MSYS, Gentoo Linux and Slackware (both distributions I use here); IMO you shouldn't have problems with other distributions unless those related to CMake version (required 2.8). Mac OSX and BSD users should test and tell what they find there. I don't have a Mac here, so I can't guarrantee you that there are no problems with it, but I have a good expectations about BSD support. Anyway, CMake is the same build platform used now by KDE, and it is regularly maintained by Kitware... My overall expectation is good regarding the building of ohcount using CMake in all non-Microsoft platforms.

Regards,

-Balena.

Guilherme Balen... over 14 years ago

My goal is to have a clean root directory. Since setup.py isn't the primary build mechanism for ohcount, it doesn't seem appropriate to me to have it in the root. But I don't care which subdirectory it lives in.

And if this would be a huge effort for you, I could be convinced to put it back in the root.

Andy Verprauskus over 14 years ago

Well, let me try if I can remove the setup.py script from the installation... I have an idea: I will try to create one more subdirectory in python dir, like 'python/ohcount'. This could work.

The current build is broken. The ohcount_sourcefile_set_filenames function has disappeared! Updated ohcount.i. Now it worked (I expect that this function won't break the tests; trying... Done, everything worked fine, seems good).

I am updating the README too, please check it out.

What I have done:

1. Updated the 'master' branch with the most recent modifications from Andy's master and updated the broken Python support (the recent 'master' branch have a broken Python extension).
2. Updated the 'python_only' branch with the most recent changes.

Guilherme Balen... over 14 years ago

I saw that ohcount is mainly implemented in C. I am looking for a python package to count LOC. Does this forum entry mean that you are working on something like an extension package for Python?
I currently need only parsers for C/C++, JavaScript, Python. I am currently looking for the options find/port/rollOwn. Maybe you want to share some opinions with me.
Are other metrics like McCabe also in scope for ohcount?

genshi over 14 years ago

Hello Genshi,

Yes, I've done a Python extension to Ohcount and it is able to count lines of code, including mixed language source files (like you have in Mozilla XPIDL files, HTML/PHP, etc.), lines of comments and blanks. Ohcount supports counting of all languages you are looking for.

I didn't understand what you mean by find/port/rollOwn, but Ohcount just count files, by now there is no McCabe complexity analysis. You can look for CCCC if you want McCabe analysis for C/C++ and Java (I don't know what is the status for supporting other languages, and I don't know how complex is to extend it for Python and JavaScript). CCCC was developed in C/C++ and Java (no Python interface/extension there; but you should evaluate the usage of SWIG to create a Python extension if you have any requirement restriction to that language)...

If you want to try the Python extension, I recommend you to use my fork at Github. I am helping Andy to fix up some final details on Python extension. The main Ohcount branch is located at andyverprauskus Github.

Best regards,

-Balena.

Guilherme Balen... over 14 years ago