Skip to content

Xcode: addon defines / cflags with $(inherited), and addons on macos / tvOS (were written to orphan objects) - #675

Open
danoli3 wants to merge 1 commit into
openframeworks:masterfrom
danoli3:xcode-addon-defines
Open

danoli3 wants to merge 1 commit into
openframeworks:masterfrom
danoli3:xcode-addon-defines

Conversation

@danoli3

@danoli3 danoli3 commented Oct 22, 2026

Copy link
Copy Markdown
Member

Fixes addon ADDON_DEFINES / ADDON_CFLAGS in generated Xcode projects, and addons in general on the macos and tvos platforms. CLI 0.113.0.

[[null], "FOO"]

The nested [null] from addDefine on a missing key was already fixed in #651 (CLI 0.112.0, auto v = j[p] instead of brace-init). On current master the remaining problems were:

Defines / flags (osx, ios, macos, tvos)

  • GCC_PREPROCESSOR_DEFINITIONS, OTHER_CFLAGS, OTHER_CPLUSPLUSFLAGS and OTHER_LDFLAGS set by addons now start with $(inherited) when PG creates the array (or converts a string value), so the CoreOF.xcconfig / Project.xcconfig defines still apply.
  • Defines, and -D / -U / -I flags, are added once even if an addon is parsed twice or the project is regenerated (other flags aren't deduplicated: -framework A -framework B are separate values).
  • ADDON_CFLAGS also go to OTHER_CPLUSPLUSFLAGS, like the makefiles. The template sets OTHER_CPLUSPLUSFLAGS at project level, so C++ never inherited OTHER_CFLAGS, and ADDON_CFLAGS = -DFOO never reached .cpp files.

macos and tvos: addons went to orphan objects

xcodeProject hard codes the osx and ios templates' UUIDs; macos (osx template + a multiplatform target) and tvos fell into the ios branch. Every addon source file, include path, define, flag and library was written into objects that don't exist in those templates (1D60588E… sources phase, 1D605894… configs, 29B97314… group), so Xcode ignored them and addon sources weren't compiled.

  • macos uses the osx UUIDs.
  • readTemplateUUIDs() reads the template's app targets, their build configurations and Sources / Frameworks / Resources / Copy Frameworks phases, and the main group's src / addons / openFrameworks groups, for anything the hard coded UUIDs don't match. osx and ios keep their hard coded UUIDs, so their output is unchanged.
  • Settings go to every app target's configurations, and files get a PBXBuildFile per target phase (the macos multiplatform target and the macOS target both compile the addon). Targets of a multi-target template keep their names.
  • bin/data is now in the project tree for macos / tvos (was an orphan), and the openFrameworks group path is no longer written to an empty key on ios when the project is outside OF.

Tests

  • New scripts/osx/test_xcode_addon_flags.sh (run from test_cmdline.sh): a temporary addon with ADDON_DEFINES = FOO BAR=1 and ADDON_CFLAGS = -DBAZ, generated twice for osx / macos / ios / tvos; checks every app target configuration has $(inherited), FOO, BAR=1 once each, OTHER_CFLAGS / OTHER_CPLUSPLUSFLAGS start with $(inherited) and contain -DBAZ once, the addon source is in each target's Compile Sources, and there are no orphan objects. Passes with this PR, fails on master (osx: no $(inherited) / no -DBAZ for C++; macos: orphans, nothing applied).
  • Structural comparison (UUIDs normalised) old vs new for osx / ios with no addons and with ofxGui: identical. macos / tvos only gain bin/data in the tree without addons.
  • osx project with ofxGui + the test addon (a source with #if !defined(FOO) || BAR != 1 || !defined(BAZ) #error) builds with xcodebuild; compile line has the xcconfig defines plus -DFOO -DBAR=1 -DBAZ.
  • Not built: the macos project's targets (the OF core openFrameworksLib macos project fails to link locally, and the template's multiplatform target points at a missing Preview Content folder — both independent of PG), ios / tvos (no simulator runtime locally).

…_CFLAGS for C++ too; macos (both targets) and tvOS read their target / phase / group UUIDs from the template so addon sources and settings stop going to orphan objects; CI regression test; bump version
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.

1 participant