openframeworks
Cairo functions from ofGraphics separated in different files.
So in near future we can build OF without Cairo.a, optionally, as discussed here
- https://github.com/openframeworks/openFrameworks/issues/6947
The idea itself was upvoted in the thread by @roymacdonald and @danoli3 If anybody has the time to proofread this PR it would be great!
@dimitre cool. Is it just that you moved the Cairo stuff from ofGraphics.* Into ofGraphicsCairo.* ? Why are you putting the include to ofGraphicsCairo.h in ofMain.h instead of ofGraphics.h? I think that that include should go in the place that the code was extracted so not to beeak the dependecies in projects. Say, someone has a project and they use #include "ofGraphics.h" to use some of the cairo related functions, with what you are proposing it will not compile and that would suck. Figuring out what was making it not to compile might take some time yet it wont harm if you put #include "ofGraphicsCairo.h" in ofGraphics.h
Thanks @roymacdonald! it does make sense. For me it is the same, as it is or as you suggest. I'll make this change if others agree.
Personally I think it is a very remote possibility and I prefer this way because we can use preprocessor definitions to customize the OF to compile "Cairoless" soon.
I mean, most of the projects includes ofMain.h and lots of addons does the same. and for 0.12 we can break theoretically compatibility a little :)
Hey @ofTheo, finally it is passing all tests and ready to review. Share your opinion on this
Reason behind this change: Sometimes we want to compile faster, or build a smaller binary file, have less time spent validating in app store, so it makes sense to aim for a modular OF where we can left out some unused functionality. I love Cairo but I don't use it in 80% of my projects, so it is great to be able to left it out, as well as freeimage, fmod, etc.
Some related threads https://forum.openframeworks.cc/t/of-lite/5170 https://forum.openframeworks.cc/t/openframeworks-lite/37256 https://forum.openframeworks.cc/t/bundling-osx-app-without-glut-and-without-fmodex-nasty/23503/4
I think there was some similar ideas shared in Denver conference in 2019 as posted here too: https://github.com/openframeworks/openFrameworks/issues/6866#issuecomment-1053783484
Definitely let’s add some macros to define stuff out where not needed, fmod, curl/ssl, Cairo. Will make future maintenance easier too
On Fri, 22 Jul 2022 at 2:18 pm, Dimitre @.***> wrote:
Reason behind this change: Sometimes we want to compile faster, or build a smaller binary file, have less time spent validating in app store, so it makes sense to aim for a modular OF where we can left out some unused functionality. I love Cairo but I don't use it in 80% of my projects, so it is great to be able to left it out, as well as freeimage, fmod, etc.
Some related threads https://forum.openframeworks.cc/t/of-lite/5170 https://forum.openframeworks.cc/t/openframeworks-lite/37256
https://forum.openframeworks.cc/t/bundling-osx-app-without-glut-and-without-fmodex-nasty/23503/4
I think there was some similar ideas shared in Denver conference in 2019 as posted here too: #6866 (comment) https://github.com/openframeworks/openFrameworks/issues/6866#issuecomment-1053783484
— Reply to this email directly, view it on GitHub https://github.com/openframeworks/openFrameworks/pull/6985#issuecomment-1192163943, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGK2HDAA3UCFEOCMX5JJFDVVIOJLANCNFSM5WHACNCA . You are receiving this because you were mentioned.Message ID: @.***>
Hello @ofTheo I've updated this branch to work well with latest. I've tested with project generator and it seems good to go. Any observations or objections on this one?
Thanks @dimitre - is the idea to do another PR later which will selectively include cairo based on MACRO / #defines? If that's the case it looks good to me.
Yes, the idea is merge this one, and work on another which involves more decisions to uniformize defines. here is the complete proposal for this one https://github.com/openframeworks/openFrameworks/issues/6947
and here a proposition of changing the way ofConstants.h is organized which we can discuss soon https://github.com/openframeworks/openFrameworks/issues/6948