-
Notifications
You must be signed in to change notification settings - Fork 74
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Addons parsing improvement (dont merge yet) #578
Addons parsing improvement (dont merge yet) #578
Conversation
…e abstract, and overriding these in derived classes
…e different elemetns an added addon. Classes extending baseProject should not call addAddon or override it, instead should override these added functions
… macos instead of osx
@roymacdonald has this been tested more since the PR? For testing Frameworks: For testing dylibs: I'd love to merge this but would be good to know how much it's been tested across platforms ( as there are so many changes it's hard to review ). |
… override declared
… rules to libfiles
…d, not following the general pattern
So far I've tested:
|
Nice. I think we should have it merged before resolving dylibs. maybe it needs more discussion. my opinion is we should remove all paths from dylibs and use them in a specific copy phase, I don't remember if frameworks or executables. it is easier to correct paths this way and dylibs find each other correctly if we use this way. |
The "@rpath" issue can be handled by the addon_config.mk via LD_FLAGS. Actually, I've been testing with ofxHapPlayer and it compiles and runs without any extra setting. In that particular case, since it sets the @rpath to the dylibs that are in the addon's folder it works with make command too. I think that dealing with the libs paths should be handled by each developer that wants to use a dlyb in their addon/app, and we should provide instructions on how to achieve such easily. |
this is a nice test: https://forum.openframeworks.cc/t/addon-makefile-clash/44076 |
Yeah definitely fine to merge @roymacdonald - especially as we are not regressing with the make file dylib stuff. |
I was actually testing this 2 days ago. it only afects make for some reason and not xcode. It requires a small change in the makefile to make it work. I will add a PR |
I will merge this. It seems that there are a lot of current issues that are solved here. Even when I have not tested it all I am confident that the areas taht I did not are the ones that I did not change. |
void addLibrary(const LibraryBinary & lib){}; | ||
virtual bool createProjectFile() override; | ||
virtual void addInclude(const fs::path & includeName) override{}; | ||
virtual void addLibrary(const LibraryBinary & lib)override{}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we can remove virtual here once it is final
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just updatetd it. THanks for pointing out. Although, the linux test fails immediately when trying to pull ubuntu
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you @roymacdonald let's merge it.
I've noticed one error here compiling with make:
it seems to work ok if we change toString functions and removeDuplicates to static |
Nice catch. I was not using make for building PG, nor tested it. |
ok merged in another PR here #583 |
awesome. Thanks @dimitre |
Thank you for the improvements in PG. |
This is what I have done so far related to this
I have encapsulated the ofAddon class so it is easier to test that it is loading/parsing properly the values for any addon.
I have dealt partially with the macos/osx issue. I say partially because I have not tested it thoroughly and it mostly feels like a hack. But so far it works for me, I am able to use addons, local addons, addons that use libraries, xcframeworks. Still neet to test for those using frameworks, system frameworks and dylibs. Currently only testing on macos 14 (sonoma) and xcode 15.
I will setup my windows/linux computer to be able to test on those other environments as well.
The main idea behind all of it is that an addon is an addon regardless of where it sits in the filesystem. Since all the routes are relative it should not matter where these sit, thus the local addons are treated in the exact same way as the non local ones.
Then the baseProject class does not do much with these besides loading and then it is the job of each baseProject-derived-class to override the necessary functions so it adds the addons properly.
There is a lot to be cleaned and reduced since there is a lot of duplicated code and stuff not even used.
Eventually it should provide a much cleaner way of dealing with addons and project creating in general.