Make single file library

[phalox]

A feature I've liked in some other projects: a single .c and .h file for your entire project. Especially with dev environments where you cannot use the make features (e.g. an IDE) it's great to have just a single file to include in your project that's pre-generated with all the right features.

I'm currently working on a little python script that concatenates all files together and removes includes. From this I've noticed some consistency issues:

• pico_md5.c includes <> style pico_md5.h (all others are done with "")
• heap.h should really be renamed to pico_heap.h
• We have a couple of references to external libraries (mainly the SSL ones). Is there a way we can move these dependencies elsewhere?

[frederikvs]

Not sure how much value this would add over just running make once, getting the .a and include files, and throwing those into your IDE. I'm a bit worried about the added complexity and possible breakage of that python script.

Those consistency issues should probably be fixed regardless of whether we go through with the one-file approach though.

[phalox]

What's the guarantee that a different compiler will be able to handle a gcc generated .a file? You still have the issue of needing a linux system and gcc installed.

Another idea I've been playing with, is to have a web application that can generate [some easy file] for you after you select some options. This entirely removes the need to even clone the picoTCP project.

Edit: referring to this: http://softwareengineering.stackexchange.com/questions/235706/are-c-object-files-created-with-different-compilers-binary-compatible

I think the only way is to have a single .c and .h file to really kickstart people with a picoTCP project, nomatter what compiler they're using. Cesanta's Mongoose conveniently supplies a single .c and .h file: https://github.com/cesanta/mongoose.

Many web libraries also have a custom builder that allows you to generate your specific image (e.g. http://jquerymobile.com/download-builder/) which gets rid of the annoyances of setting up all your dependencies correctly. It could even supply template code or compilable simple examples...

The more I look at it, the more I have to acknowledge that we have a usability problem in general. Our full dev environment is focussed on Linux, while the reality tells us that many people/companies are not running on linux and not using gcc compilers... I think we can take some really nice steps towards greater usability of which this could be one.

[phalox]

I've created a SO question for this too: http://softwareengineering.stackexchange.com/questions/339166/different-ways-to-distribute-embedded-c-modular-library

Seems that a single .c and .h file that include all sources is the best way to go; As an added bonus it might improve the performance of the stack. I also went through the SQLite example who do the same (they call it Amalgamation). One gotcha: some compilers might not be able to handle a giant .c file; therefore they also split them up in multiple smaller files, while using 1 main .c file that #include subcfile1.c

I'll spend a bit more time on my script to see if I can generate something clean. I still have issues with the correct ordering of header files.

[hermanius]

Does it match with the modularity options of picoTCP? Can you still excludes modules with compiler options?

On 31 Dec 2016, at 09:54, Toon Peters notifications@github.com wrote:

I've created a SO question for this too: http://softwareengineering.stackexchange.com/questions/339166/different-ways-to-distribute-embedded-c-modular-library http://softwareengineering.stackexchange.com/questions/339166/different-ways-to-distribute-embedded-c-modular-library Seems that a single .c and .h file that include all sources is the best way to go; As an added bonus it might improve the performance of the stack. I also went through the SQLite example who do the same (they call it Amalgamation). One gotcha: some compilers might not be able to handle a giant .c file; therefore they also split them up in multiple smaller files, while using 1 main .c file that #include subcfile1.c

I'll spend a bit more time on my script to see if I can generate something clean. I still have issues with the correct ordering of header files.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/tass-belgium/picotcp/issues/441#issuecomment-269856230, or mute the thread https://github.com/notifications/unsubscribe-auth/AP02UaViK1yiUyU20uU6xk6ItAalSj1_ks5rNhgrgaJpZM4LXiUA.

[phalox]

It doesn't change a thing. In fact we can take a very easy step in this direction: add #ifdefs for compilation flags over the entire C file already. This will allow people to just dump the whole picoTCP project in their environment and after setting the right flags it will work.

[frederikvs]

I've thought about it some more, and I think you're fixing the wrong problem here. I've never thought "I really want to use this library, but it's more than one file, so it's too difficult to use".

You still have the issue of needing a linux system and gcc installed.

We don't depend on gcc, nor on linux, and what I said about building the .a once and including it still applies. Our jenkins compiles the stack for both GCC and clang, and we try to be as compiler-independent as possible - there's a bunch of other compilers on the README.md. As for Linux, I can tell you that the stack compiles without issue on my macOS. Under windows it should also work, assuming you have something that parses a makefile. And if you don't, it should still compile if you have some other script to compile it with.

Our makefile is gcc-centric, that's true. But if you want to use another compiler, it's either a minor makefile edit, or just an alias for gcc. However, I do agree that we should improve the documentation of this. We have issue #439 and #440 for that.

And when it comes to putting it in your IDE, we have a wiki page devoted to that : https://github.com/tass-belgium/picotcp/wiki/Porting-the-build-to-another-compiler---IDE If you don't want to go through adding the files to your IDE, you can just use your IDE's compiler from command line once, have it generate the .a file, and then dump that in your IDE for linking into the build. I think all IDEs allow you to use the compiler from some external script as well, otherwise you have bigger problems than including some files.

Anyway, I think solving the documentation problems should solve 90-100% of the problem you're trying to fix here.

[SvenMey]

Hey guys

I do not believe in merging/concatenating all into 1 file. An IDE, or even compiler for that matter, not able to handle project directories and makefiles seems odd to me. Most can even read "gmake-files".

Giving a good overview on module hierarchy and their dependencies, together with clear/same module structure would suffice.

KR