[riot-notifications] [RIOT-OS/RIOT] Build dependencies - processing order issues (#9913)

Gaëtan Harter notifications at github.com
Tue Apr 23 15:38:24 CEST 2019

> > Reuse Makefile.features to define CPU
> > But I am not going to push toward having 3 times the cpu name defined between Makefile.features, Makefile.dep, Makefile.include.
> @cladmi There is probably something obvious I'm missing but why couldn't CPU definitions be moved to Makefile.features instead of re-defining CPU in this file?

I was referring to the alternative if not moving it which would result in the same thing as this type of lines https://github.com/RIOT-OS/RIOT/blob/c7e26377ea5752ff6139ea96c043b60e03246b2b/boards/iotlab-m3/Makefile.features#L5 where currently the cpu value is "re-defined" without using the CPU variable. So somehow the value is currently duplicated.

I was questioning if it should go in `Makefile.features` or if it could be another file.
My reasoning is that it could be a move toward defining the hierarchy for defining a BSP with all the board/common/cpu/arch but should be another task even if it duplicates moving them now that I have more feedback.

> I think before doing this we need uniform the definitions of CPU_FAM for all cpu that already have some form of this concept. To be specific I'm talking about Kinetis where there is KINETIS_(Family, subfamily and series) and a CPU_FAMILY (used only for specifying the openocd script).

I would prefer do it in an independent task as it has its own specific requirements. But it can indeed be done before if it works.

Re-ordering is "only" solving the dependency order issues and is a stupid to do change.
Where changing the names questions the definition of the names and need to look in all cpus.

We had a discussion about it with @kYc0o and I think from what I remember:
* CPU_MODEL is the full CPU identifier
* CPU_FAM/CPU_FAMILY has a meaning to the outside as a family
* CPU only the directory in `cpu` and can have the value `CPU_MODEL`,`CPU_FAM` or something different

But not all variables are always defined so there are inconsistencies.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/notifications/attachments/20190423/11f635e5/attachment-0001.html>

More information about the notifications mailing list