Build problems with makefiles

[kashperanto]

Hey, I thought I would give this library a try tonight, and I am having some trouble getting it to build on my system.

Running make in any of the example programs is failing in the call to tar to unzip the cproto-4.7m.tgz file. After running this several times trying to debug it I noticed that I had a dozen "cproto-4.7.m.tgz.N" files in my test/ folder. It appears to be downloading the tarball every single time, but fails to find it when trying to extract it because it is looking in the wrong directory.

I managed to "finish" the build from the root cutest/ directory by modifying cproto.mk, but my change didn't work in the example directories. It seems that one of the commands is not being run where it thinks it is being run.

I am not wise enough in the ways of makefiles to figure out what is wrong here, but it seems like this should be fairly reproducible. I am using Ubuntu on Windows Subsystem for Linux, and have installed all of the prerequisite packages as far as I can tell.

[aiobofh]

Hi @kashperanto, right :) Unexpected that someone would actually try it out.

I have not given this product much love the last years though. But... It worked quite well once. On the other hand I have thought about my approach on-and-off since, and have actually a newer thing along the same tecnique, but even more compiler agnostic and such...

OK. So.. Question: Did you grab master or a released version? Master might be severly broken, in general. Sorry about that.

I would almost say cutest is abandmed in favor of my newer project (which I haven't had much time with either in the last year or so). But it would be AWESOME to get feedbacks anyway. So let's try to figure this out.

I know the Makefile magic is powerful in this one. But it's also therein the power/speed comes from. I myself never had the ambition to have it run perfectly on Windows, but at some point it was running fine. But again: That's ages ago, but also a good sign that it should be able to get it working again.

Hm. What if... You download cproto on-the-side and use that binary instead of using the quirky patchy thing I did to genericly build it from scratch? Do you think it's doable? If you take a looksie on line 43 of cproto.mk there is a commented line where it tries to locate a pre-installed cproto-4.7m. I think that if you get that piece of Makefile running you should have a nice parser to get the C function prototypes out of your C-code.

[kashperanto]

Hey, thanks for the reply; I was honestly surprised I never saw this one until now. I actually was looking at a separate c project that used a different "cutest" framework that was very basic (no mocking whatsoever). I noticed this one while I was searching through github and was persuaded by your example-based documentation.

I currently use Ceedling for testing embedded C code on my host (no intention of doing on-target unit tests at the moment). It works well, but uses Ruby tools to parse code and generate mocks, which are inserted at link time (so within one test file you either mock or don't mock the headers, no combination of module/unit tests is possible). I like the idea of how you are doing the mocks (which I'm curious to learn in more detail how it works). Ceedling has a very hard time with some mocking due to nested header includes, which are common in embedded system drivers (to give a family of similar chips a common interface).

The C11 integration is cool for variadic macros. Since we're not running on target it should be easy to support these new features for tests on the host system.

I think I grabbed master, but I will give it another go with the latest tagged commit, using your suggestions. I did see cproto in ubuntu's apt repository, so I can just install it on my system that way. WSL actually gives this tool full "Windows compatibility", since you can just apt-get all of the dependencies in Ubuntu (or a few other distros iirc).

I would be interested in your newer project if you wanted any feedback. I'm an embedded C guy, so maybe a different perspective could be useful (although I'm quite deficient in the more detailed linuxy things like autotools/etc).

[aiobofh]

@kashperanto ok :) fun that you found it tho.

The automatic generation of mocks and the quite minimalist approach might be both good and bad.

Sure - I'll see if i can share with you the newer framework (based on the ideas and principles of cutes). It has WAY fewer dependencies. For example cproto be gone. It will build itself a few tools instead to parse and generate mocks, also a test-suite generator and such. This reduces the complexity of the build system quite a bit. I'll try to find some time this week. Are you using gcc?

[kashperanto]

@aiobofh Cool, it will be interesting to see what you have. Is it still all written in C?

Even though Ceedling is quite capable, the fact that it is written in Ruby is a bit off-putting for me. I don't have anything against Ruby as a language, but as an embedded developer I can't justify learning it to be able to help develop the tool. Something based in the language I'm most familiar with seems more appropriate (even if a high-level language would be more appropriate in general for this type of thing).

Don't hurry on my account, and yes I am using gcc. My philosophy is that unit tests on the target are not a good use of time, so all of my unit tests are on the host PC (Ubuntu 18.04 running on Windows 10 in WSL).

[aiobofh]

@kashperanto great. Sounds like the new stuff would be fun for you to take a looksie at then.

Yeah. I mean, most things can be solved on unittesting on host, not target. However, since my framework (both cutest and the new one) does not rule that out, I (as a proud parent) see them as ideal for embedded development tools/help to get code in a good quality.

The new framework is actually even more pure C code. It reduces the need for *NIX tools in general via the Makefiles. Not much grep and sed going on at all, actually. This was one of the things of cutest that made med frustrated - the very complex build-system required. I just want to write my test-file, and write my code-file and be a happy camper. And cutest also has a few nice-to-have things that turned out quite complex to maintain. E.g. on a test-failer, re-run the exact same test with gdb to get a stack-trace and such nice things. I currently have no plans to keep doing such sugar, however convenient.

Anyways - I'll try to get the stuff up here on Github, in some state, and we could have a discussion, maybe on another channel than a Github issue :) I'm on IRC, for example (efnet and ircnet. (without the "bofh")).

[aiobofh]

@kashperanto hey again. I'm getting close to getting the stuff on github, or some other means of publication. If you're curious check this out: https://www.aio.nu/tarsio.html please give feedback :)

[kashperanto]

@aiobofh Hey, I was about to check it out and noticed that the download links are broken (url not found). I read through the manual, and it sounds like a good approach.

I like that the TDD (CDD) approach solves one pitfall with this (and pretty much all other C testing platforms) in that the auto-generated code does not play nice with code completion tools.

Ceedling/CMock somewhat gets around that by using link-time substitution after generating mocks for specified files (#includes marked with "mock_*"), but this is only good when it works. It is not a real C compiler/preprocessor, and can't handle much of the craziness that older embedded code and some libraries use.

I like your strategy for inserting the mocks - it sounds very portable and easier to reason about.

[aiobofh]

@kashperanto right... Yeah, I have not put the code there. I think I will iron out a few quirks and put it here on github instead. Problem is leisure-time :D I have gotten a lot of things done. I need to fix licence files and a few tiny more things, then we're here :)

I'm very glad you like the ideas! (not all people "get it"). And I hope you will be able to try it out quite soon. Bare with me! If you're interested in the tool-chain you're more than welcome to contribute once it's up here too :)

About inserting mocks. Yes, it's very portable - but not all C-compilers are playing nice. Time will tell if it's a good plan, or if customizations are needed for various compilers. I hope not.... Hence I tried to make the parsing very "loose" to accept various weird coding styles and pre-processed C. Fingers crossed!

[aiobofh]

@kashperanto just pushed the stuff to github :) https://github.com/aiobofh/tarsio is the new project see you there.