Project build

[fnadeau]

Is there a reason why the there is a mix of cmake and makefile in the project? Are the makefile still supported?

[thoni56]

Yes, both are supported. You can do either

make

which is simple and natural for most users, or

mkdir build; cd build; cmake ..

which requires that you are familiar with CMake incantations.

The Makefile in the top directory is a fairly thin layer on top of CMake and sets up the CMake configuration as required. That makes it easy to build in the "natural" manner on the platform while still allowing for tweaking all the CMake complexity if you want. It also supports a few targets including the following targets

make debug

which sets up for debug compilation which is not so obvious using plain CMake, and

make unit

which runs the tests using visible Cgreen feedback rather than hiding it in CTest.

Personally I always use make and resort to CMake tweaking only when necessary.

Again, it is still CMake that does the heavy lifting by configuring for your environment. So, if you are contributing to the Cgreen project and need to make a change to the build (e.g. searching for a library that hasn't been used in Cgreen before) you should add your changes to the appropriate CMakeList.txt.

[fnadeau]

Thanks for the information. It sure is simple to just run make.

tools/Makefile does not seem to be used and contain out of tree reference: ../../pycparser-master/utils/fake_libc_include

[thoni56]

Well, depends on what you mean by "used". As is stated in the beginning of that Makefile it is intended to just run unittests for the runner. I could not make that possible using Cgreen itself inside the framework of CMake since it requires some "magic" to mock away the I/O part. And incidentally that's where the "out of tree", or even "out of repo" reference comes from. It uses the cgreen-mocker, which in turn uses a faked libc from pycparser, to auto-generate the mocks for the I/O-layer to keep that updated.

But given your workrecent with replacing that, thanks for that btw., it should be possible to remove that dependency and get it running without the fake library. But then I dont think there is much value left, since the unittests basically tested that the discoverer could interpret the nm output correctly.

[thoni56]

And there's something more .... ;-)

In src there is also a Makefile but it just cd:s to the root and hands over to that Makefile. This is also a convenience Makefile for the case when you are in Emacs editing a file in src and want to build: M-xcompileEntermake unitEnter.

I'm a sucker for streamlining...

And obviously, the Makefile in doc/tutorial_src is to build those sources to ensure they work and can be included in the documentation (which they are using AsciiDoc includes...).

[thoni56]

The answer is also partly in the guide section 1.3.2

[fnadeau]

CMake and Makefile both have (among other things) one goal: dependency management. Having both cmake and makefile in the same project makes that dependency management complicated. One example:
this will fail

git clone https://github.com/cgreen-devs/cgreen.git
cd cgreen
make -j9 unit test

but this will work

git clone https://github.com/cgreen-devs/cgreen.git
cd cgreen
make -j1 unit test

Which hint that dependency are not well managed.

I agree that cmake is more complicated than makefile, but it seems to me that in this case, the makefiles are used as a script wrapper to cmake.

My 22 cents, a bash script could probably do the same level of abstraction without the dependency management issue.

[thoni56]

Good point! Although make is already in your reflexes, ./build (or something similar) not as much.

[thoni56]

Fixed. The target "test" is now dependent on building.