[bug :: macOS] bin/data in DerivedData breaks user interaction with ofToDataPath()

[artificiel]

so the actual ofToDataPath() is buried in DerivedData (ex: /Users/brtn/Library/Developer/Xcode/DerivedData/myDeliberateSketch-aqwtovqchnmcfrazakooakhzrkco/Build/Products/Debug/data) so the actual data dir is not bin/data... might no be apparent for static ressources, but things like ofxWatchFile, ofxAutoReloadedShaders do not work as expected because watched ressources are those within DerivedData. and of course anything saved to disk will be thrown in DerivedData.

[eduardfrigola]

I encountered the same issue when saving an image via ::ofSaveImage, but any place using ofToDataPath() is broken as you pointed out.
Might be related to: #8276

Cc @danoli3

[ofTheo]

Yeah - been struggling with this since the 'clean wipes the bin/ folder' fix.
I have messed around with a million different solutions but none seem ideal.

Currently I believe the behavior is the following:

• apps are run from myAppProjectFolder/DerivedData/myApp/Build/Products/Release or Debug
• apps are copied back to myAppProjectFolder/bin/ so that they can be run from there too.

This means:

1. apps that save files or change files aren't updating the data/ folder in bin/ and a clean will wipe those saved files changes.
2. any projects that assume an app location and are loading relative file paths will fail ( we have a couple of addons with large resources than can be loaded from the addon folder during dev and this breaks that )

1. is pretty killer and makes the current situation less than ideal.

A proposed fix:

1. instead of copying data/ to DerivedData/myApp/Build/Products/Release move the compiled app back to bin/ as a post build step
2. modify the project scheme to run the Debug and Release executable from the bin/ folder instead of the default value which is the compiled app location

This will allow clean to work as intended ( except it won't delete the compiled app which is fine ) and files will be saved to the correct location in bin/.

The only issue is getting 2) working.

Looking into it now.

Ref for where you can manually set the app to run via the gui.
Looking into ways we can set this via PG or Project.xcconfig

[dimitre]

I prefer the old behavior, bin generate inside data, no way of clearing project, no special attributes on folder.
I'm keeping this way in the fork I'm using.
archiving / send to app store working ok there

[dimitre]

And tested some projects with 3Gb 3d models in data folder
takes a while to sync and uses more disk space

[ofTheo]

@dimitre do you know what it was that prevented the old behavior from cleaning the bin/ folder?

[dimitre]

yes. no scripts changing the attribute of bin folder

[dimitre]

you can see them on macos / osx template, one of the first scripts on Build Phases

[danoli3]

Setting of the CONFIGURATION directory forced Xcode clean function into the bin/data deleting the folder, so any files or folders there, not meant to be used as a final directory hence the name.

It was not the setting of attribute of files within it that changed anything, that just allowed Xcode to clean files in its paths to clean, unfortunately it seems Apple used rm -rf on that directory.

Can't use it due to the rm -rf.

Cleaning is so important for development

We can petition Apple to create a new output variable or final binary

I always use BUNDLE data always since thats the only way to really build macOS apps anyway.
Maybe should have a split

DATA path (input) (internal data folder)
DATA path (output) external folder (bin/data)

This would solve a lot of problems of having write out operations and file input loads separately clearly

Again iOS can now have an output folder that is Cloud Drive / USB-C Drive / External so its use of data output would be useful there too outside of bin/data loading

[ofTheo]

CONFIGURATION_BUILD_DIR = $(SRCROOT)/bin/ has been in OF since at least 0.11.2.

If I clean on older 0.12.0 or 0.11.2 projects the bin/ folder doesn't get wiped.

However if I add the script @dimitre mentioned to an 0.12.0 project it wipes the whole bin/ folder on clean.

So the script is definitely responsible as it marks the bin/ folder as a folder CreatedByBuildSystem ( and therefore safe to delete ) which technically it is not.

I always use BUNDLE data always since thats the only way to really build macOS apps anyway.
Maybe should have a split

Yeah, for distribution especially bundling is great, but our use case is quite different and involves collaborators working with the data/ folder.

Anyway, this is definitely a regression.
I'm going to keep looking into a better fix - open to other suggestions too.

#!/usr/bin/env bash

# Determine the Xcode build directory
TARGET_DIR="${BUILT_PRODUCTS_DIR:-$SRCROOT/bin}"

# Check if the directory exists
if [ ! -d "$TARGET_DIR" ]; then
  echo "Error: Target directory $TARGET_DIR does not exist."
  exit 1
fi

# Check and set the com.apple.xcode.CreatedByBuildSystem attribute
ATTRIBUTE_CHECK=$(xattr -p com.apple.xcode.CreatedByBuildSystem "$TARGET_DIR" 2>/dev/null)
if [ -z "$ATTRIBUTE_CHECK" ]; then
  xattr -w com.apple.xcode.CreatedByBuildSystem true "$TARGET_DIR"
  echo "Attribute com.apple.xcode.CreatedByBuildSystem set to true for $TARGET_DIR"
else
  echo "Attribute com.apple.xcode.CreatedByBuildSystem already set for $TARGET_DIR"
fi

[dimitre]

I've investigated CONFIGURATION_BUILD_DIR = $(SRCROOT)/bin/ and it was in OF forever, at least surely in 0.9.8
what happened is sometime I ported configurations from XML file that was a hell to read / edit to the xcconfig file.

[dimitre]

This attributes are not needed for archiving and distribution on app store.
Not sure if you mention direct distribution between different computers @ofTheo