search

premake / premake-core

Premake
https://premake.github.io/
BSD 3-Clause "New" or "Revised" License
3.2k stars 618 forks source link

How to handle conflicting API (in external modules)? #2184

Open Jarod42 opened 7 months ago

Jarod42 commented 7 months ago

What's your question?

I test external modules, I put generators in premake5-system.lua I have one project which uses one module with "conflicting" api same name, (and even same definition) leading to errors. Which is the proper way to handle that?

For actual case, it is premake-qt and premake-qmake with api qtmodules.

Anything else we should know?

From https://github.com/dcourtois/premake-qt/pull/33

The proper way to fixing that would be to have the ability to create addon namespaces, but that's something that needs to be solved in Premake-core.

samsinsane commented 2 months ago

This is tricky. You could probably override api.register yourself and kind of hack in a namespace. The simplest would be to just prefix something to name but then you would need to call the APIs using _G["prefix.api"] "value" instead of prefix.api "value". There might be some Lua trick to get it to work as expected, or you can just add _G["prefix"]["api"] = _G["prefix.api"] then both ways of calling the API will work.

However, this won't do anything for any instances of modules overriding the same function. Especially ones that extend call arrays and perform the same checks, like this: https://github.com/premake/premake-core/blob/fa2405d4857c13b625bce8159e0d03cbb058aa43/modules/android/vsandroid_vcxproj.lua#L43-L56

Pulling in another Android module that extends VS would likely result in the same kind of override being performed and both will execute and result in two entries for androidApplicationType. Similarly, two modules overriding the same function using the same conditions may cause only one of the overrides to work, this would be an issue for a function like this needing to change/extend the potential values: https://github.com/premake/premake-core/blob/fa2405d4857c13b625bce8159e0d03cbb058aa43/modules/vstudio/vs2010_vcxproj.lua#L1741-L1753

So, while you might be able to avoid the situation of two modules adding the same API and causing an error, you won't be able to avoid the situation of two modules extending the same function. The only way to truly do that is to not load both of them together.