Esp-idf: The build procedure doesn't handle components with the same name

[Sermus]

Let's assume i have the following directory structure:
bundle1\utils\component.mk
bundle2\utils\component.mk
If i add bundle1\utils and bundle2\utils to SRCDIRS only one of them will be built. The reason is that the build procedure handles the components by their names, so the targets created for one of those components override the targets for the other one.

[Spritetm]

It's not a bug, it's a feature :) this allows you to override components that are specified elsewhere; for example, if you need to modify the bootloader, you can copy the esp-idf component over from the esp-idf tree to your own project and modifying it there instead of having to hack into the (possibly shared) main esp-idf tree.

Can I suggest coming up with some slightly more descriptive component names than 'utils'? In general, I'd say it's good practice to name things after what they do and try not to use generic names like that.

[Sermus]

Jeroen,
The description was probably oversimplified. I understand the reason behind what you're explaining. However let's imagine i should port pieces of software to esp32. If i accidentally have same name components inside these pieces i'm in trouble. Obviously i wouldn't like to rename components in the software i don't own because this may turn maintenance into a nightmare.

As far as i see from the makefiles the only reason is that the component's intermediate files are created in flattened manner in the build folder. Can we introduce some flexibility to the build procedure by letting developer turn off this "just introduce the same name component to override the existing one" feature because in some cases it has a bit of uncontrolled behaviour?

[ESP32DE]

@Spritetm
please do not change this genial "future" :)
we work with this here and this is the goal to handle overlay user things to the base component in the esp-idf, this is very welcome.

@Sermus
understand you -
we handle yours

bundle1\utils\component.mk
bundle2\utils\component.mk

with

components\utils1\component.mk
components\utils2\component.mk

and we get
libutils1.a
libutils2.a

best wishes
rudi ;-)

edit:
if you need this bundle's

components\bundle1\utils\component.mk
components\bundle2\utils\component.mk

libbundle1.a
libbundle2.a

[Sermus]

Rudi,
I didn't mean to change the default behaviour. I understand a lot of people use this feature. I just asked if we can have an option to disable this behaviour.

[ESP32DE]

@Sermus
think i have overread the word "option" ;-)
sry .

but yes as option this would be welcome too,
so we can compile in one difference versions from them.
sometimes this would be nice to switch all off and only our project compos were compiled that we want to have

best wishes
rudi ;-)

[Spritetm]

@Sermus As far as I am aware, components are things that are highly esp-idf specific. If you would port another piece of (non-esp-idf) software over, you would dump it inside a single component. (At least, that is how I do it and that seems the most logical way to me.)

Yes, there is an option to have a namespace collision in two existing esp-idf components that are both from third parties. I would however posit that would indicate a name that is too generic on the side of the component makers, and should be seen as a bug.

Is there any real-world scenario where you run into a problem like this? I don't mind introducing specific options and behaviour if it solves a real problem, but you haven't convinced me yet that this actually is an issue that cannot be solved in a way that is way more useful (=using less generic names for components)

[Sermus]

Hi Jeroen,
Yes, there is a real case. We're porting our IoT platform from 8266 to 32. We have a number of components and subcomponents. Some of the subcomponents have identical names which were inherited from the software initially ported to 8266.
Decision to use IDF component phylosophy/configuration and build principles to handle these components and subcomponents within ESP ecosystem was quite logical. Personally I find configuration and build principles you put inside IDF to be very convenient. The only glitch now is that name collision.
I understand i can refuse using IDF build procedure within my components, make my own one and export the whole piece of my code as a single component to IDF. This would mean i were inventing a wheel which was already invented by you. Frankly speaking if i had to do that i'd do something very similar to what you did in IDF. So the question why should i? Does it make sense to maintain two almost identical build procedures diverging only in that component handling aspect?

[projectgus]

We have a number of components and subcomponents. Some of the subcomponents have identical names which were inherited from the software initially ported to 8266.

I think "subcomponents" is something of a new idea to IDF, where we largely imagined a "flat" component structure (possibly with multiple components folders, but not with any nesting of components.)

Would you be able to flatten these out to a single layer, keeping the "components" but moving the "subcomponents" into their parents?

[Sermus]

Ok, i've got own build procedures for these components.