[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:
https://github.com/RIOT-OS/RIOT/issues/9913#issuecomment-485806391
-------------- 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