the nightly build does not work with 3rd party boards

[braindevices]

I am testing RFduino recently. I can compile and upload successfully when using arduino IDE 1.6.5. However, the eclipse plugin cannot add system includes resulting compiler failure with missing file like "chip.h".
RFduino has these lines in the "boards.txt ", which have not been respected:

RFduino.build.variant_system_include="-I{build.system.path}/RFduino" "-I{build.system.path}/RFduino/include" "-I{build.system.path}/CMSIS/CMSIS/Include"
RFduino.build.variant_system_lib=libRFduinoSystem.a

These includes are not in the projects.
I also try to add values build.variant_system_include="-I{build.system.path}/RFduino" "-I{build.system.path}/RFduino/include" "-I{build.system.path}/CMSIS/CMSIS/Include" and build.variant_system_lib=libRFduinoSystem.a in the platform.txt. Still it does not have any effect at all.

the build.system.path is empty. If I add "build.system.path={runtime.platform.path}/system", it will work.

However, the combiner won't work properly, it seems put all arduino related *.o in release/arduino/ instead of release. Changing {build.path}/syscalls.c.o to {build.path}/arduino/syscalls.c.o in the platform.txt solved this problem.

any idea where to start to fix it? Is the current code respect all setted value or using fixed value?

[braindevices]

in ArduinoHelpers.java it has following lines:

} else if (architecture.equals("sam") || architecture.equals("mtk")) {
        Common.setBuildEnvironmentVariable(contribEnv, confDesc, ENV_KEY_build_system_path, makeEnvironmentVar(ENV_KEY_PLATFORM_PATH) + "/system");
        Common.setBuildEnvironmentVariable(contribEnv, confDesc, ENV_KEY_build_generic_path, makeEnvironmentVar(ENV_KEY_HARDWARE_PATH)
            + "/tools/g++_arm_none_eabi/arm-none-eabi/bin");
    }

This means it can only handle certain kind of boards but not customized or 3rd-party boards. Shouldn't we always create the ENV_KEY_build_system_path for all the boards if the "build.system.path" has not been defined?

I also found the code handle the combiner for sam and mtk. I think this way seems too rigid to handle increasing amount of hardwares. Why can't we just put all *.o in {build.path} instead of {build.path}/arduino as the arduino IDE always does? At least we should do replacement for syscalls_*.c.o in a more flexible way. For example, regex replacing the {build.path}/syscalls_.*.c.o to {build.path}/arduino/syscalls_.*.c.o. However, putting all *.o in the same level of dir will be much easier and more flexible.

[jantje]

I made a blog post on this subject.
http://blog.baeyens.it/#post22
I hope this helps you out.
Best regards
Jantje

[braindevices]

@jantje Thanks a lot!
I would like to help to make the project more flexible for different boards, unless you think it is too difficult to do that. Would you please clear few things for me before I start to try anything out?

1. why the avr, sam and mtk are handled in a hard-coded way? Is it just legacy or is there some specific reason for that? If it is too difficult to get rid of those hard-coded parameters I guess I have to give up.
2. is the DUMP_..._ArduinoIDE.tmp generated by arduino --board --get-pref ?
3. why we need subdir during compiling? Can we just output all object files to build root as the arduinoIDE did? I guess I could probably modify the ArduinoGnuMakefileGenerator.java to generate mk file with target as "xxx.c.o" instead of "arduino/xxx.c.o".

[jantje]

Help is welcomed. but ....it is all far more complex than it looks ;-)
1: sam is there because I do not control the platform.txt from arduino. (Cant add it to platform.txt => add it to the defaults). The guy who implemented mtk just copied my behaviour. (it must be somewhere here in an issue or pull request) After I explained I think he fixed it in the platform.txt file. For arduino IDE 1.6.5 I think this is pure legacy (also for sam arduino). But lots of users use older versions of the arduino ide.
2: yes
3: Arduino ide has a much finer control over the build process than you have in CDT.
For an arduino project you need to build a library and a program. In cdt speak that are 2 projects. This is how the plugin V1 works. I changed this in V2 and that was needed because from 1.5 onwards compilation options impacted the library. So the rule "one board one library" was no longer possible -Teensy is a board I use and has this requirement to-. It was hard work to get it done and my first English blog post dealt with it http://blog.baeyens.it/#post1.

One of the problems is knowing the difference between "code that needs to be archived" and "code that only needs to be linked".
The .o files in the arduino folder are the ones that need to be archived before they are offered to the linker.
Note that I had to change some internal classes from CDT to get it to work. Some were pure bug fixes which I reported -including fix- but .....

[jantje]

I'm closing this as a duplicate of #158
If this is not your problem please reopen.