picoTCP (an open source embedded TCP/IP stack) has always had a development focus (both in picoTCP itself and with picoTCP) on linux & gcc systems. The final target is usually an embedded micro (ARM based). For this reason we put quite some logic into the makefile to keep modularity high. We're also using compile flags to enable/disable all of these modules.
We start to notice that Linux isn't the only developer system (here I mean while using picoTCP in your own project) in the world and that Windows together with a bunch of IDEs with each their own (proprietary) compiler aren't good friends with Makefiles.
This usually means that these users have to manually add the picoTCP files to their project and expand their build system. This also means that people get into issues like
- which files to include (because the logic is in the Makefile)
- in which order they should be included
- manually update all these files when there's a new version
We're currently looking at the different ways of how to distribute picoTCP in a more convenient way and would like to know the pros and cons.
We've currently identified a couple of ways
Generate .a file
- (+) Clean solution that keeps using the existing Makefile
- (-) Needs a Linux & gcc environment
- (-) Only works for the same target compiler/system
Generate a single .c and .h file
This is something the Mongoose library from Cesanta does
- (+) Very portable & simple to use
- (-) Nightmare to do debugging
- (-) Will need external scripts to remove #includes and merge files together
- (-) All modules would be included, therefore we'll probably have to add some more compilation flags
Build a (web-based) library generator (again one .c and .h file)
Something commonly done in web applications (like JQuery)
- (+) Assists people in building an optimized library
- (+) Web based, so no need for any environment
- (-) The most work to set up such a system
- (-) How to keep track of many library versions ?
Could you provide comments and more alternatives?