Skip to content
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

Merged
merged 68 commits into from
Nov 2, 2024

Conversation

roymacdonald
Copy link
Contributor

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.

@ofTheo
Copy link
Member

ofTheo commented Oct 3, 2024

@roymacdonald has this been tested more since the PR?

For testing Frameworks:
https://github.com/astellato/ofxSyphon

For testing dylibs:
https://github.com/design-io/ofxOrbbec

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 ).

@roymacdonald
Copy link
Contributor Author

So far I've tested:

  • Macos(xcode)

    • addons
    • local addons (arbitrary relative path)
    • static libs (xcframeworks and .a)
    • dynamic libs(linked and copied into app bundle)
    • additional sources
  • Macos(make)

    • addons
    • local addons (arbitrary relative path)
    • static libs (xcframeworks and .a)
    • dynamic libs(linked and copied into app bundle)
      this step needs to happen as part of the make build config we have, and make an upgrade to it rather than injecting that code into it via PG. But this is how it has been all the time.
    • additional sources
  • Macos(VSCode)
    relies on make. So what generates the projects is fine.

  • iOS, tvOS, (other apple devices)
    Nothing tested on it. I don't have a device for testing

  • Windows (VS)

    • addons
    • local addons (arbitrary relative path)
    • static libs
    • dynamic libs(dll's linked and copied next to executable)
    • additional sources
  • Windows (make)
    not tested so far. BEcause of how it works, PG is not changing anything in there, just copying the templates. Thus, independend of PG

  • WIndows(VSCode)
    Not tested so far, although uses make.

  • Linux(QT)
    Nothing tested on it.

  • Raspberry PI
    Nothing tested on it, yet relies on make.

  • Android
    Nothing tested on it.

@ofTheo @dimitre @artificiel

@dimitre
Copy link
Member

dimitre commented Oct 29, 2024

Nice. I think we should have it merged before resolving dylibs.
the problem with dylibs is most of the time they use some built in paths. like in the case of @rpath/ffmpeg/lib/osx/libavutil.56.dylib in ofxHapPlayer

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.

@roymacdonald
Copy link
Contributor Author

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.

@artificiel
Copy link
Contributor

@ofTheo
Copy link
Member

ofTheo commented Oct 30, 2024

Yeah definitely fine to merge @roymacdonald - especially as we are not regressing with the make file dylib stuff.
Really excited for this one!

@roymacdonald
Copy link
Contributor Author

this is a nice test: https://forum.openframeworks.cc/t/addon-makefile-clash/44076

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

@roymacdonald
Copy link
Contributor Author

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.

@roymacdonald
Copy link
Contributor Author

damn, I don't have write access here. @ofTheo @dimitre , can you merge please?

void addLibrary(const LibraryBinary & lib){};
virtual bool createProjectFile() override;
virtual void addInclude(const fs::path & includeName) override{};
virtual void addLibrary(const LibraryBinary & lib)override{};
Copy link
Member

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

Copy link
Contributor Author

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

Copy link
Member

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.

@dimitre dimitre merged commit e9e9562 into openframeworks:master Nov 2, 2024
2 of 3 checks passed
@dimitre
Copy link
Member

dimitre commented Nov 2, 2024

I've noticed one error here compiling with make:

duplicate symbol 'toString(LibraryBinary const&)' in:
    /Volumes/tool/ofw/apps/pgd/commandLine/obj/macos/Release/src/projects/android2024.o
    /Volumes/tool/ofw/apps/pgd/commandLine/obj/macos/Release/src/projects/CBWinProject.o
    /Volumes/tool/ofw/apps/pgd/commandLine/obj/macos/Release/src/projects/CBLinuxProject.o
    /Volumes/tool/ofw/apps/pgd/commandLine/obj/macos/Release/src/main.o
    /Volumes/tool/ofw/apps/pgd/commandLine/obj/macos/Release/src/projects/baseProject.o
    /Volumes/tool/ofw/apps/pgd/commandLine/obj/macos/Release/src/utils/Utils.o
    /Volumes/tool/ofw/apps/pgd/commandLine/obj/macos/Release/src/projects/VSCodeProject.o
    /Volumes/tool/ofw/apps/pgd/commandLine/obj/macos/Release/src/addons/ofAddon.o
    /Volumes/tool/ofw/apps/pgd/commandLine/obj/macos/Release/src/projects/androidStudioProject.o
    /Volumes/tool/ofw/apps/pgd/commandLine/obj/macos/Release/src/projects/visualStudioProject.o
    /Volumes/tool/ofw/apps/pgd/commandLine/obj/macos/Release/src/projects/xcodeProject.o
    /Volumes/tool/ofw/apps/pgd/commandLine/obj/macos/Release/src/projects/qtcreatorproject.o
duplicate symbol 'toString(std::__1::__fs::filesystem::path const&)' in:
    /Volumes/tool/ofw/apps/pgd/commandLine/obj/macos/Release/src/projects/android2024.o
    /Volumes/tool/ofw/apps/pgd/commandLine/obj/macos/Release/src/projects/CBWinProject.o
    /Volumes/tool/ofw/apps/pgd/commandLine/obj/macos/Release/src/projects/CBLinuxProject.o
    /Volumes/tool/ofw/apps/pgd/commandLine/obj/macos/Release/src/main.o
    /Volumes/tool/ofw/apps/pgd/commandLine/obj/macos/Release/src/projects/baseProject.o
    /Volumes/tool/ofw/apps/pgd/commandLine/obj/macos/Release/src/utils/Utils.o
    /Volumes/tool/ofw/apps/pgd/commandLine/obj/macos/Release/src/projects/VSCodeProject.o
    /Volumes/tool/ofw/apps/pgd/commandLine/obj/macos/Release/src/addons/ofAddon.o
    /Volumes/tool/ofw/apps/pgd/commandLine/obj/macos/Release/src/projects/androidStudioProject.o
    /Volumes/tool/ofw/apps/pgd/commandLine/obj/macos/Release/src/projects/visualStudioProject.o
    /Volumes/tool/ofw/apps/pgd/commandLine/obj/macos/Release/src/projects/xcodeProject.o
    /Volumes/tool/ofw/apps/pgd/commandLine/obj/macos/Release/src/projects/qtcreatorproject.o
duplicate symbol 'toString(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const&)' in:
    /Volumes/tool/ofw/apps/pgd/commandLine/obj/macos/Release/src/projects/android2024.o
    /Volumes/tool/ofw/apps/pgd/commandLine/obj/macos/Release/src/projects/CBWinProject.o
    /Volumes/tool/ofw/apps/pgd/commandLine/obj/macos/Release/src/projects/CBLinuxProject.o
    /Volumes/tool/ofw/apps/pgd/commandLine/obj/macos/Release/src/main.o
    /Volumes/tool/ofw/apps/pgd/commandLine/obj/macos/Release/src/projects/baseProject.o
    /Volumes/tool/ofw/apps/pgd/commandLine/obj/macos/Release/src/utils/Utils.o
    /Volumes/tool/ofw/apps/pgd/commandLine/obj/macos/Release/src/projects/VSCodeProject.o
    /Volumes/tool/ofw/apps/pgd/commandLine/obj/macos/Release/src/addons/ofAddon.o
    /Volumes/tool/ofw/apps/pgd/commandLine/obj/macos/Release/src/projects/androidStudioProject.o
    /Volumes/tool/ofw/apps/pgd/commandLine/obj/macos/Release/src/projects/visualStudioProject.o
    /Volumes/tool/ofw/apps/pgd/commandLine/obj/macos/Release/src/projects/xcodeProject.o
    /Volumes/tool/ofw/apps/pgd/commandLine/obj/macos/Release/src/projects/qtcreatorproject.o
ld: 3 duplicate symbols

it seems to work ok if we change toString functions and removeDuplicates to static
I can to a PR with this and move this functions to inside ofAddon, because it is the only place that uses it

@roymacdonald
Copy link
Contributor Author

Nice catch. I was not using make for building PG, nor tested it.
Making those static would be a good idea, but also putting those toString functions inside a namespace, something like of::priv:: which is used elsewhere.
If you can make those changes it would be great

@dimitre
Copy link
Member

dimitre commented Nov 2, 2024

ok merged in another PR here #583
I'm manually generating a nightly build so we can inspect examples to see if they are OK in windows / mac

@roymacdonald
Copy link
Contributor Author

awesome. Thanks @dimitre

@roymacdonald roymacdonald deleted the addonsParsingImprovement branch November 2, 2024 23:02
@dimitre
Copy link
Member

dimitre commented Nov 2, 2024

Thank you for the improvements in PG.
when you have time take a look at the issues to close the ones addressed in your PR

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants