switching platform name from osx to macos messes up everything

[roymacdonald]

After using the updated version of Apothecary I noticed that the libs/osx will be renamed to libs/macos. While this makes sense in terms of following the correct naming of apples OS it breaks so many things, in particular with project generator. Now for instance I cant use addons that have compiled libs in them such opencv.

(I've been battling with PG's code in order to make it work properly with local addons and this issue is really annoying).

Although this switch could be compensated through code, it means more work and testing for something that still does not work correctly (such as PG). I think it is a good idea to roll back to osx rather than macos. Having it done in the first place is the sort of thing where the saying "why fix it if ain't broken?" applies perfectly. What do you think @dimitre @danoli3 @ofTheo @2bbb

[artificiel]

what I understood in @danoli3's comments in https://github.com/openframeworks/openFrameworks/issues/8038 is that macos is not just about renaming file paths but supporting a consolidated approach across apple outputs; in essence it's a different platform than osx. there are specific OF_ROOT/scripts/macos and /osx directories.

(taken from line 87 in /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/TargetConditionals.h)

*    +--------------------------------------------------------------------------------------+
 *    |                                    TARGET_OS_MAC                                     |
 *    | +-----+ +------------------------------------------------------------+ +-----------+ |
 *    | |     | |                  TARGET_OS_IPHONE                          | |           | |
 *    | |     | | +-----------------+ +----+ +-------+ +--------+ +--------+ | |           | |
 *    | |     | | |       IOS       | |    | |       | |        | |        | | |           | |
 *    | | OSX | | | +-------------+ | | TV | | WATCH | | BRIDGE | | VISION | | | DRIVERKIT | |
 *    | |     | | | | MACCATALYST | | |    | |       | |        | |        | | |           | |
 *    | |     | | | +-------------+ | |    | |       | |        | |        | | |           | |
 *    | |     | | +-----------------+ +----+ +-------+ +--------+ +--------+ | |           | |
 *    | +-----+ +------------------------------------------------------------+ +-----------+ |
 *    +--------------------------------------------------------------------------------------+

I'm all for modernisation, but things might be more deeply ingrained than apparent, and "swapping" osx for macos is not as straightforward (notable, addon_config presumably needs to be tweaked to support both as download_libs passes 'macos' as the platform).

work on macos should be done without compromising osx, not renaming it. currently the bin nightly release tagged 'osx' contains scripts/osx but e.g. libs/freetype/lib/macos/freetype.xcframework (as opposed to libs/freetype/lib/osx/freetype.a in 12.0)

[roymacdonald]

Thanks @artificiel for your comment. I agree with keeping up to date but I think that it needs to be done in a more thoughtful way and as you day without compromising what's already there. I see that there are a lot of new issues that seem to be related to this issue. I have a working version PG that deals with this issue along with others. I will post it soon. Cheers

[danoli3]

I’ll get back to the dailies soon and explain all this soon

On Wed, 25 Sep 2024 at 9:58 am, Roy Macdonald @.***> wrote:

Thanks @artificiel https://github.com/artificiel for your comment. I agree with keeping up to date but I think that it needs to be done in a more thoughtful way and as you day without compromising what's already there. I see that there are a lot of new issues that seem to be related to this issue. I have a working version PG that deals with this issue along with others. I will post it soon. Cheers

— Reply to this email directly, view it on GitHub https://github.com/openframeworks/apothecary/issues/437#issuecomment-2372595095, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGK2HHIOSHA5UFQQX764STZYH4BPAVCNFSM6AAAAABOYTI4DSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNZSGU4TKMBZGU . You are receiving this because you were mentioned.Message ID: @.***>

[roymacdonald]

https://github.com/roymacdonald/projectGenerator/tree/addonsParsingImprovement

[dimitre]

I would love to have "osx" name kept similar paths and libraries layout as it was before, so "macos" could be the new template using xcframework. this way we could have day to day projects untouched and test "bleeding" when feeling adventurous.

I think this is really a needed cleanup and we should respect this using a section called "osx" and another explicit one called "macos" to get addon libraries right.

[ofTheo]

Yeah I think my preference ( if it is not doing this already ) is that if we have macos paths supported we also support osx for the considerable future.

I think it's fine if our libs/ folder starts using macOS for the xcframework etc but for 3rd party addons etc and other projects we should be treating osx the same so both are supported.

[roymacdonald]

In the project generator PR I have I already added support for both of this methods, It works fine so far with xcode. I am testing with the full set of features; local addons, external code, addons that use other frameworks, static or dynamic libs, etc. I will setup my other computer with windows/linux computer so I can test there.

I am quite impressed by how well the makefiles work, it is quite seamless to be honest and I guess it has not been touched for quite a while. And because such, vscode works pretty well and its setup is very minimal.

I am not sure how to achieve it but it would be great to leave the whole project generation thing (particularly for xcode) in the hands of some other software (cmake, cocoapods, I dont know) because we are spending a lot of energy on something that others have done and that is very badly documented.