xcode projects bug on 0.8.1 osx realease

[roymacdonald]

I was testing the 0.8.1 osx release on osx 10.6.8 and xcode 4.2 and everytime I opened an xcode project it showed up empty.
The solution to this is to remove the file project.xcworkspace from inside the .xcodeproj
Xcode will rebuild the xcworkspace and it will work correctly. I guess that this is because of my old OS and those xcode projects were generate on a newer os.
On the other hand, if I create a new project using the project generator the newly created xcode project contains the project.xcworkspace file even if it is not inside the template project in scripts/osx/template so I guess that PG might be taking it's tamplate from somewhere else.
Hope someone can fix this in the release zip.

best

[ofZach]

if you can, can you post both xcworkspace files online for comparison?

also, I'm pretty sure the PG is copying this over:

https://github.com/ofZach/projectGeneratorSimple/blob/master/src/projects/xcodeProject.cpp#L209-L210

[roymacdonald]

actually the xcworkspace that comes in the release projects is empty.
In the template xcodeproj there's no xcworkspace.
So I guess that the PG is creating this empty xcworkspace so to place inside of it what it should copy form the template but as there´s nothing to copy it just creates the empty xcworkspace.
Thus, when opening the project with the empty xcworkspace xcode gets confused and shows it as empty instead of generating the correct on.

[ofZach]

yes I was just taking a look and it seems this file was removed a while back. @arturoc @bilderbuchi this change was introduced around here:

815b2b7#diff-a15b09f1d119dd7889b77825fded1918

I'm not sure why this file was deleted, maybe accidentally? pinging @admsyn also since you were looking at the template.

[admsyn]

Interesting, I don't remember ever messing with .xcworkspace files..

The project.xcworkspace files are indeed gone from scripts/osx/template/emptyExample.xcodeproj though. Xcode 5 doesn't seem to need them, and I don't have an Xcode 4 install around to reproduce and dig into this :/

@roymacdonald does it work fine if you extract the project.xcworkspace from OF 0.8.0's emptyExample template and drop them into the 0.8.1 one?

[roymacdonald]

@admsyn It worked with the xcworkspace extracted from v0.8.0. :)
I guess that just restoring this file and removing it from the gitignore should work.

[bilderbuchi]

The solution to this is to remove the file project.xcworkspace from inside the .xcodeproj
Xcode will rebuild the xcworkspace and it will work correctly.

This indicates to me that XCode can generate this file itself correctly. The root cause of Roy's problem is probably that the line in the PGS that Zach linked to should be removed, as it is referencing a file which doesn't exist anymore, and thus generates an empty file called contents.xcworkspacedata. Then XCode sees that the file exists already (and thus does not create it itself), and subsequently chokes on the malformed (i.e. empty) contents of said file.
As I don't have a Mac available, this is theorycrafting, but from what Roy describes (i.e. if you delete the file manually, everything works), I feel this could be the correct solution.

That the PG has to be adapted was something we/I didn't realize in the original PR which introduced that change. Sorry 'bout that.

Those files got cleaned out in e17e584 because they were in the repo, but matched a gitignore rule.
As for the rationale for removing contents.xcworkspacedata (which removed the containing folder as it was then empty, see this comment and the following ones. @ofTheo confirmed here that this file is not needed.

[ofZach]

oddly, I can't see how this is producing an empty file, which seems like a bug somewhere:

https://github.com/openframeworks/openFrameworks/blob/master/libs/openFrameworks/utils/ofFileUtils.cpp#L730-L762

https://github.com/ofZach/projectGeneratorSimple/blob/master/src/utils/Utils.cpp#L107-L139

it's easy enough to remove these lines, but maybe @ofTheo can jump in about why this file is not needed?

[ofZach]

I see the error, it's actually creating a folder that this file should live in -- but not copying the file in:

https://github.com/ofZach/projectGeneratorSimple/blob/master/src/projects/xcodeProject.cpp#L208

so it's not an empty file but rather, an empty directory. waiting to hear from @ofTheo about why this file is removed. it's seem potentially important when you look at it and not user specific...

http://stackoverflow.com/questions/8628530/which-xcode-project-files-can-i-exclude-from-my-git-repo
http://stackoverflow.com/questions/10956312/is-the-project-xcworkspace-file-important

[ofTheo]

Sorry just catching up on this.
The file is not needed for the project generator. If we can stop it being copied. / generated then Xcode should auto generate the correct one.

Or we can add it in, but I think it's easier to not include it.

[ofZach]

it's actually not getting copied, we're just making the folder for it since it used to be there and get copied and we needed a folder for it.

I'm fine to remove it from PG, but it looks somewhat important -- it doesn't look user specific. from that stackoverflow:

Generally, the contents of the project.xcworkspace directory contains the contents.xcworkspacedata file, which lists the projects that are included as top-level entities in your project,

[bilderbuchi]

so what happens when we also not make that empty folder? Does it work then?

Zach, if you quote that answer you cited a bit more completely, it also says "In environments where you don't share workspaces, or where you use simple workspaces, you can ignore these as well, however in environments where you put related projects in the same workspace and share that configuration, you may well want to keep these."

I guess another question is, do we have any "projects that are included as top-level entities in your project", whatever that may be? The original contents of the xcworkspacedata file don't look terribly non-default. There's at least no OF library reference in there, and it really looks like something that would just be autogenerated:

<?xml version="1.0" encoding="UTF-8"?>
<Workspace
   version = "1.0">
   <FileRef
      location = "self:PROJECTNAME.xcodeproj">
   </FileRef>
</Workspace>

[bilderbuchi]

Also, just a gut feeling, but if we ship as few files as we can get away with, there's gonna be less headache keeping the PG working for different versions of XCode, based on the simple fact that there's one less file to generate/check/keep up-to-date/tweak according to version/etc., especially if XCode generates that file itself when necessary, anyway. Correct?

[ofZach]

I think that's totally fine, we just need to make sure we (a) test this (b) sync with PG. It looks like removing this file has no issues in either xcode, and is generated automatically, but it's not 100% clear to me what this file is and why we would or wouldn't want it. Also, it didn't create any problems before... now, just having the folder without the file is causing an issue. I realize we don't want specific user files, but this does seem to be a needed file, so we're just making it be autogenerated instead of supplying it ourselves.

Here's a useful xcode gist btw which might shed some light on the format in xcode:
https://gist.github.com/driesvints/4389062

[roymacdonald]

Hi,
So it seems that the relevance of the .xcworkspace directory is quite undocumented.
So far, OF has been delivering it just as an empty folder and xcode builds it correctly.
As far as for the OF projects it seems to be not needed but it might be for other projects. So to create OF it shouldn't be a problem not to create it, and in the case that a user need it to be there it will be created automatically by xcode.
I think that removing the lines from PG should be fine, yet as Zach says it need to be tested.
I can test on osx10.6.8 and xcode 4.2 and osx 10.8.x and xcode >4.2
best

[arturoc]

This happened to me during a workshop this weekend, no one could see the
files, fortunately 0.8.0 worked without problem. Not sure what's the
best solution, but we should fix it asap.

On Mon, 2014-04-14 at 16:49 -0700, Roy Macdonald wrote:

Hi,
So it seems that the relevance of the .xcworkspace directory is quite
undocumented.
So far, OF has been delivering it just as an empty folder and xcode
builds it correctly.
As far as for the OF projects it seems to be not needed but it might
be for other projects. So to create OF it shouldn't be a problem not
to create it, and in the case that a user need it to be there it will
be created automatically by xcode.
I think that removing the lines from PG should be fine, yet as Zach
says it need to be tested.
I can test on osx10.6.8 and xcode 4.2 and osx 10.8.x and xcode >4.2
best

—
Reply to this email directly or view it on GitHub.

[ofZach]

I'd much rather replace that file that didn't break anything (!) then change the PG, recompile it, create new releases.... but at any rate, I just put in fixes, but against master not against 0.8.1 tag. I really don't feel like replacing zips is right this late after a release, I feel like we ought to increase release counts on stuff like this.

new compiled pgs for testing: https://dl.dropboxusercontent.com/u/92337283/OF/projectGeneratorIOS.zip
https://dl.dropboxusercontent.com/u/92337283/OF/projectGeneratorOsx.zip

again, my intuition is the opposite of @bilderbuchi - this file, which isn't really well documented, wasn't causing anyone issues anywhere and seems necessary to the project (because it gets regenerated), so a much simpler fix is to reintroduce it then change the PGs, etc.

[ofZach]

ps we should really test this on a bunch of osx / ios / codes. we have a tendency to get the packaging around this wrong and there are so many configurations of xcode / osx that have peculiarities (as roy's shown us) !

(also, it's a good sign that we need a more rigorous testing process if this wasn't caught after several RCs)

[bilderbuchi]

yes, either way to solve this suits me. you guys as users of xcode probably have a better intuition about what's proper anyway. if you include the file again, please also make sure to adjust the gitignore pattern (and don't force-add).
+1 about testing, XCode 5 will probably relevant to test, also.

I really don't feel like replacing zips is right this late after a release, I feel like we ought to increase release counts on stuff like this.

absolutely, strictly speaking, we shouldn't replace zips at all, more frequent releases are the proper solution here.

[arturoc]

+1 to doing a new release

[arturoc]

+1 to doing a new release, by the way we don't need to include the
latest changes in master, we can just fix this in a different branch and
do a release from it.

On Tue, 2014-04-15 at 07:02 -0700, Christoph Buchner wrote:

yes, either way to solve this suits me. you guys as users of xcode
probably have a better intuition about what's proper anyway. if you
include the file again, please also make sure to adjust the gitignore
pattern (and don't force-add).
+1 about testing, XCode 5 will probably relevant to test, also.

    I really don't feel like replacing zips is right this late
    after a release, I feel like we ought to increase release
    counts on stuff like this. 

absolutely, strictly speaking, we shouldn't replace zips at all, more
frequent releases are the proper solution here.

—
Reply to this email directly or view it on GitHub.

[bilderbuchi]

The stable is intended for things like this - branch off from current stable(I.e. 0.8.1), fix the bug, PR back to stable. Subsequently merge to master.

[ofZach]

can we test the new project generators? I have this PR here,

#2935

maybe it can be cherry picked against stable? (Or do you want me to resubmit again against stable).

Personally, I think the file should go back, in a sort "do least harm" approach -- but at any rate, I've supplied a fix in code and compiled PGs, they need some attention if others are having this problem. Sounds fairly urgent to fix -- I have never seen this personally (my students who are installing OF new seem to be ok, for example) but it would be good to get some sort of fix out.

[roymacdonald]

Hey Zach.
the projectGenerator worked for me, on osx10.6.8 and xcode 4.2,
yet the projectGeneratorSimple didn't get updated. I guess that I did something wrong with git.
I did the following:

git remote add ofZach https://github.com/ofZach/openFrameworks.git
git fetch ofZach
git checkout -b xcodeProjFix  ofZach/xcodeProjFix

How do I update the project generator simple?
Probably you haven't seen this problem with your students as they might be using a newer os and xcode.

best

[bilderbuchi]

Roy, you can update the submodules with git submodule update --init.

[ofZach]

Roy can you try the zips?
https://dl.dropboxusercontent.com/u/92337283/OF/projectGeneratorIOS.zip
https://dl.dropboxusercontent.com/u/92337283/OF/projectGeneratorOsx.zip

[roymacdonald]

Hey Zach,
both worked fine. I placed the PG inside fresh copies of their respective
OF v0.8.1 distro. It seems to me that it is ok at least for osx10.6.8 and
xcode4.2
Best

Roy Macdonald
+569 8248 8478

On Sat, May 3, 2014 at 4:24 PM, ofZach notifications@github.com wrote:

Roy can you try the zips?
https://dl.dropboxusercontent.com/u/92337283/OF/projectGeneratorIOS.zip
https://dl.dropboxusercontent.com/u/92337283/OF/projectGeneratorOsx.zip

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/2931#issuecomment-42115451
.

[pizthewiz]

Sounds like this one too is fixed yeah?

[arturoc]

yeah thanks!