Interesting pull request to add build options

The STM32 guys have added an interesting pull to their core. It lets you add a build_opt.h to your sketch files. That file is then used as the @ file on the command line. This lets you override defines in the core things like F_CPU etc before any includes. With the libmaple core this approach might be a simple way to control the -DSERIAL_USB or the-DCONFIG_MAPLE_MINI_NO_DISABLE_DEBUG flag from a user sketch instead of at the board level. Useful for flags you might want to add the boards.txt file but you skip it because you don’t want to disrupt every sketch.

https://github.com/stm32duino/Arduino_C … 2/pull/174

This change came out of a questions someone else had about the STM32 core and I proposed a solution however I didn’t really implement it. I just suggested an approach that might work. Fred has taken the idea and realized it quite nicely.

https://github.com/stm32duino/Arduino_C … /issues/41

This might be something to think about for the libmaple core.

+5
but only if it does not break anything in the existing build process.

bricks built on bricks built on bricks, the trick is to realise when to put the roof on +5
srp

Thanks Rick

that’s very interesting

What happens if the file is not present ?
According to the PR, it gets created if it’s not present, but I could not see what created it.

It’s certsinly a very powerful feature, and would resolve a number of problems, which require defines to be added to the build

Do you know if libraries can supply this file or whether it’s only the main sketch ? ( because I know the IDE does strange things like copying various files to a temp directory to compile them, I wonder if this file put inside a library could end up in the temp build directory

Rick

I read the other link, and I can see how you propose to create the file using another external script, but I don’t see that script in STMs change.

Perhaps they are using the feature for some other purpose?

Sorry.. but here is another question

Can the recipe hooks have different scripts on different platforms ?

It would need to support the same sort of system which the upload recipies use.
I presume the Arduino team implemented this

[RogerClark – Mon Dec 11, 2017 7:52 pm] –
I read the other link, and I can see how you propose to create the file using another external script, but I don’t see that script in STMs change.

[RogerClark – Mon Dec 11, 2017 8:14 pm] –
Sorry.. but here is another question
Can the recipe hooks have different scripts on different platforms ?

He takes care of both of your questions with what he is doing here:

+# Pre and post build hooks
+recipe.hooks.prebuild.1.pattern.windows=cmd /c “if not exist {build.path}\sketch\build_opt.h mkdir {build.path}\sketch & type NUL > {build.path}\sketch\build_opt.h”
+recipe.hooks.prebuild.1.pattern.linux=bash -c “[ -f {build.path}/sketch/build_opt.h ] || mkdir -p {build.path}/sketch && touch {build.path}/sketch/build_opt.h”
+recipe.hooks.prebuild.1.pattern.macosx=bash -c “[ -f {build.path}/sketch/build_opt.h ] || mkdir -p {build.path}/sketch && touch {build.path}/sketch/build_opt.h”

He uses the file called build_opt.h instead of the file I proposed. I used a txt file but that is not something you can add as a new tab in the Arduino IDE. You can add a .h file though and that is what he looks for. He checks to see if the sketch has that file using the recipe hooks above. If the file doesn’t exists, he uses the target platform to create an empty build_opt.h … using ‘type NULL >build_opt.h” on windows and “touch > build_opt.h” on linux and osx’

[stevestrong – Mon Dec 11, 2017 5:59 pm] –
+5
but only if it does not break anything in the existing build process.

Absolutely!

My response to this stemmed from another stm32duino Core PR request that was hacking up the boards.txt file to deal with sketch level configuration that can’t be done easily. I’ve not kept the modification I made to test this out. It was more an experiment to see if what I was going to propose would work.

This change is kind of out there as far as Arduino IDE platform mods go. I personally think the Arduino IDE needs a way to make command line define changes on a per sketch basis. It doesn’t offer a native solution. This is just working within their bounds to try and get something that might work. It is unlikely this approach will get buy in from the official Arduino platforms. This is the main reason I didn’t even suggest this as a github issue or pull. Just something to ponder.

Hi Rick

I don’t see any problems with adding this, because if no build_opt is specified, it should make no difference

The .txt vs .h, its a shame the IDE can’t support .txt because I agree its not ideal calling it .h, but its probably better than the other naming options that are available

Thanks Rick.

[RogerClark – Mon Dec 11, 2017 7:43 pm] –
Do you know if libraries can supply this file or whether it’s only the main sketch ? ( because I know the IDE does strange things like copying various files to a temp directory to compile them, I wonder if this file put inside a library could end up in the temp build directory

I will check that Roger.

[RogerClark – Mon Dec 11, 2017 9:53 pm] –
I don’t see any problems with adding this, because if no build_opt is specified, it should make no difference

Right, that’s the goal.

[RogerClark – Mon Dec 11, 2017 9:53 pm] –
The .txt vs .h, its a shame the IDE can’t support .txt because I agree its not ideal calling it .h, but its probably better than the other naming options that are available

About .h extensions, it is to avoid creating scripts for each OS and be able to open it with the IDE (which copy it automatically in {build.path}/sketch folder at the start of build).

They are several pre and post build hooks which can be useful:
https://github.com/arduino/Arduino/wiki … ce-ide-165

Note: I do not test it for Mac OS, if someone could test.

Frederic

Thanks

I have a Mac, so I will try to test it later

[fpiSTM – Tue Dec 12, 2017 5:17 am] –

[RogerClark – Mon Dec 11, 2017 7:43 pm] –
Do you know if libraries can supply this file or whether it’s only the main sketch ? ( because I know the IDE does strange things like copying various files to a temp directory to compile them, I wonder if this file put inside a library could end up in the temp build directory

I will check that Roger.

So, no it’s not possible as the library file are copied in {build.path}/libraries/<name of the lib>
It should be possible by adding the same mechanism with the recipe.hooks.libraries.prebuild.NUMBER.pattern (called before libraries compilation)
But I think it will add too much issue (different file name, what about having several libraries….).

Currently, I advise to use only one build options file at sketch level to avoid any confusion.

Frederic

I agree. It is not worth the effort etc to have this for libraries at the moment

I’ve made some test and succeed to enable some options for libs.

One example using the STM32Ethernet and LwIP libraries:
Adding in build_opt.h:
-DLWIP_DEBUG=1 -DLWIP_DBG_TYPES_ON=LWIP_DBG_ON -DIP_DEBUG=LWIP_DBG_ON "-DAPI_LIB_DEBUG LWIP_DBG_ON"

OK

Normally I find I can edit the source in a library, using an external editor (Notepad++) and I don’t need to reopen the IDE etc

The only time I need to close and open the IDE is when I make changes to platform.txt or boards.txt

Yes when you edit the source it is rebuilt but in this case it is not part of the source that’s why it is not rebuilt as it do not see any change.
with Arduino 1.8.x, change in the platform.txt do not require restart of the IDE. only the boards.txt requires a restart or at least open the boards manager.

Frederic

I didn’t realise Arduino 1.8.x didnt need to restart for changes to platform.txt, that’s useful to know.

Oh my, my, my …

I really have mixed emotions about this implementation; In My Experience, work-arounds are rarely completely thought-out. Which is to say that they become fragile since the implementation is often implemented without a full team vote.

In any event, the need for programmer override of the runline has been needed for a long time. There is only one correct place to put such a feature and that is in the JAVA IDE … be it a menu driven option or be it in a “fixed” tab. Personally, when the IDE loads a boards file, that file and any other pertinent files should be parsed and loaded into the IDE for observation/modification in building a NEW project and then written out into the project folder to be re-read and used in the future. Arduino makes it crazy difficult to ‘snap’ a project for delivering to a larger audience. In this regard, it needs to work like the Cypress IDE where a new project copies into the project all named libraries and configurable options such that a project can be easily backed-up.

Ray

Even though I proposed this, I’m only half excited about it. I really wasn’t advocating for its immediate implementation. I agree with mrburnette that it would be better implemented in the Arduino IDE. Sadly, it seems change happens on the IDE at a glacial pace with little regard for things that benefit Non-Arduino boards.

I think Fred has done a nice job implementing it. Maybe his stm32 core can be a guinea pig and we can see what issues appear. For the libmaple core, I think we should take a wait and see approach.

Yes you’re right. It definitely have to be in the IDE.
Anyway, instead of adding several custom menus or modifying boards.txt, I think hooks feature could help to make those customization easier for the end user.
I will extend it to rebuild all if the build options file is changed.