Rework library connection logic

[webconn]

For now, if I want to create a new external library compatible with Antares buildsystem, I need to add its "src" and "include" directories to src/ and include/ dirs of Antares, and also add some lines in Makefiles and kcnfs. The problem is about merging modified Makefiles and kcnfs with Antares updates.

There must be some more pretty solution for this. (How about auto-including Makefiles and kcnfs from custom library's directory? If it will be possible, we'll just need to symlink lib's directories to Antares tree and get happy)

[nekromant]

This is what is being done (with a little hack) with architectures under src/arch and deploy methods. During the bootstrap phase we generate tmp/arch.kcnf and /tmp/arch.mk and include those. For libraries things are a little bit different. First, it may not be flat one level deep structure and it will likely never be. In fact once all the esp8266-frankenstein goodies will be merged back into antares things will get way more complicated. Second, I'm not a big fan of keeping libraries in external git repos, since it will lead to pretty much the same thing as you have with arduino - fragmentation, and people will end up with 'collect all the libraries you need over the internets' quest). I really think that forcing people to send patches back into the main tree this way is a good idea, for it has served linux kernel a good job. if you really want that - there's also a hacky way @pastcompute described here: https://github.com/nekromant/esp8266-frankenstein/issues/53

[webconn]

This way is quietly good, I agree. But I think that there should be a way to add some external libraries which are specialized for some especial projects, and large enough, and at the same time keep Antares untouched for successfull updating. I mean that such libraries could be developed outside the Antares tree.

[nekromant]

The problem is, that huge projects, e.g. lwip, vusb require quite a LOT of hackery before they can be integrated with kconfig. That's the price. As for updating - git rebase -i does a pretty nice job here.

[pastcompute]

@nekromant I came up with a better way than what I previously described - see example code

Essentially, I have frankenstein as a submodule, then I simply re-patch or replace main.c with my own code, patch Makefile with an extra objects-y pointing to my own directory and copy my own .config over the top. Very simple and effective, and very easy to keep frankenstein in track with upstream, and any changes necessary to frankenstein itself are easy to find and either propose as upstream changes or maintain in a branch

In fact with two small tweaks I'd likely not need to patch it to use it as a base O/S

• Have a CONFIG item 'use alternative user_main'
• Have a CONFIG item like 'add extra objects'

Working for me very nicely at the moment, and it wont matter whether you move things around or into Antares