Makefile: dedicated source, include and build folders

[LukasP46]

Hey all, I rebuilt the makefiles to work so that there are dedicated source, include and build folders. In my experience such a separation has advantages in terms of keeping track. What are your thoughts?

It would be some extra work to make it compatible with the upstream and to change all the examples, so I wanted to ask if these changes would be welcomed at all.

[stnolting]

Hey @LukasP46!

The files of the SW framework are already split across source and include folder. These can be extended by the makefiles APP_INC and APP_SRC variable. So I wonder, what did you exactly extend there? ;)

and build folders

This is a really nice idea! Right now the object files of the software framework (sw/lib) are located right inside the source folder. This is unpretty but also quite dangerous as they might be re-used by another software project that uses a different MARCH/MABI configuration. Hence, you always need to do make clean_all...

So yes, I really like this! Do you use project-local build folders?

[LukasP46]

Hey @stnolting,
thank you for your fast reply!

So I wonder, what did you exactly extend there?

I mean that each "firmware project" has a structure like the following, which allows having multiple source and header files for each project in separate folders:

└── my_firmware_project
    ├── build
    │   ├── core            # build from sw/lib
    │   │   ├── crt0.S.o
    │   │   ├── neorv32_aux.c.o
    │   │   ├── neorv32_cfs.c.o
    │   │  ...
    │   ├── main.asm
    │   ├── main.bin
    │   ...
    ├── include
    │   └── fsm.h
    ├── source
    │   ├── main.c
    │   └── fsm.c
    └── makefile

Right now the object files of the software framework (sw/lib) are located right inside the source folder

As you can see in the folder structure, this would move to build/core (suggest another name if you have one :) ).

Hence, you always need to do make clean_all

This target wouldn't be needed anymore, at least for that. I actually have another results folder with Intel hex and verilog style output from the bootloader (a pull request for i2c eeprom loading is coming soon) and application that I'm keeping track of with git and following some sort of release concept. I guess this is too specific for the upstream, right?

So yes, I really like this!

Glad to hear! :)

Do you use project-local build folders?

As you can see in the folder structure, yes.

[stnolting]

which allows having multiple source and header files for each project in separate folders:

That should already be possible using the local makefile variable, right? So I wouldn't change all the default projects.

As you can see in the folder structure, this would move to build/core (suggest another name if you have one :) ).

Oh ok. I thought about one build folder for everything. There should not be any name-collisions, so this should be fine?! 🤔

I actually have another results folder with Intel hex and verilog style output from the bootloader

That's also a nice idea but for simplicity (and backward compatibility) I would just keep those "final artifacts" in the root directory.

a pull request for i2c eeprom loading is coming soon

That sounds interesting! What are you planning??

[LukasP46]

That should already be possible using the local makefile variable, right? So I wouldn't change all the default projects.

I've changed quite some bit, but you're actually right, using the local makefile should work! I'll give it a try and probably publish a PR this week :) Maybe with an example project folder with separate source and header folder? And the other example should still just work fine without it.

I thought about one build folder for everything. There should not be any name-collisions, so this should be fine?!

I haven't thought about it

I just did it to maintain some overview in the build folder as I regularly look at some files, like the assembler output, manually and this helped me. But if it's bad style or overkill, I could remove it :)

That's also a nice idea but for simplicity (and backward compatibility) I would just keep those "final artifacts" in the root directory.

Yes, I won't add there anything then. I also have my rtl-and sw-common files where else and as such my workflow is a bit incompatible anyways.

That sounds interesting! What are you planning??

Thanks! I2C EEPROMS are just very present in the industry and are cheap. If pin count is too expensive for SPI, I2C might be a alternative. Though the startup is rather slow and Firmware size very limited (at least with one address byte). If I actually gonna use it, I don't know, but I wrote the bootloader extension, so why not share it :)

[stnolting]

I'll give it a try and probably publish a PR this week :)

Thanks! I'm locking forward to it!

Maybe with an example project folder with separate source and header folder? And the other example should still just work fine without it.

That sounds good. Maybe sw/example/coremark would be a nice candidate?!

I just did it to maintain some overview in the build folder as I regularly look at some files, like the assembler output, manually and this helped me. But if it's bad style or overkill, I could remove it :)

I'm not sure - I think it is just a matter of taste. For me I like having everything in one place. But I'm also not very experienced with software development.

Yes, I won't add there anything then. I also have my rtl-and sw-common files where else and as such my workflow is a bit incompatible anyways.

Did you change that just to make it clearer for you or do you have any highly experimental features being in progress?

Though the startup is rather slow and Firmware size very limited (at least with one address byte). If I actually gonna use it, I don't know, but I wrote the bootloader extension, so why not share it :)

That sounds cool! I really like the large-capacity I²C FRAMs (~512kBit) from Cypress/Infineon - I always wanted to add a "boot from I²C device" option to the bootloader. Unfortunately, it was running out of memory... 😅

[LukasP46]

I also have another question if we decide to bumb the clean_all target: what should happen with the image_gen tool? Should it also get build into the build folder? Seems a bit unnecessary. Maybe the clean_all target should remain just for that.

[stnolting]

what should happen with the image_gen tool? Should it also get build into the build folder? Seems a bit unnecessary.

I think that would be an overkill 😅

Maybe the clean_all target should remain just for that.

Good idea!

[LukasP46]

Pull request created: #1107