search

DragonBuild / dragon

pip install dragon | A Powerful buildsystem and toolkit currently targeting darwin (iOS/macOS) machines
MIT License
220 stars 23 forks source link

Project specific variables affect global namespace in DragonMake #50

Closed nicolas17 closed 3 years ago

nicolas17 commented 3 years ago

If I have a DragonMake containing a type: tweak module followed by a type: cli module, the cli executable is wrongly built as a shared library. The reason seems to be that the type definition for tweak in defaults.yml sets lopts: '-dynamiclib ...', and the definition for cli has no lopts at all. Instead of causing an empty lopts, this makes it keep the old value from when it processed the tweak, so it passes -dynamiclib when building the cli executable too.

Putting the cli module first and the tweak module second fixes the problem. Setting lopts: '' in the definition of cli in defaults.yml also works.

Similarly, the cli module gets wrongly linked to Foundation and CydiaSubstrate if it's defined after the tweak in the DragonMake, but not if it's defined first.

0cyn commented 3 years ago

Pushed a hotfix for this but I'm leaving it open as I really need to take a look at why those settings are carrying over.

Someone wrote some "optimized" logic for loading in the config files; I'm wondering whether these 'defaults' are getting pointed to when they should be copied instead.

0cyn commented 3 years ago

There's a problem somewhere in DragonMake logic that causes the variables to behave as globals instead of properly adhering to their namespace.

I am entirely unsure how that's possible given the current control flow of the DragonGen code. This can be solved by redefining the variable causing issues for each project. Having to do so is not intended behavior, and this is an important issue that reduces QOL when writing build scripts.

now that pip migration is complete i'm going to look into this again.