Fix #791: Add support for Xcode

jeroenbakker-atmind commented 8 months ago

Description

Xcode projects were not able to link. The reason is that libtool (linker) doesn't support to sharing same name in a single library. Framework uses 4 files with the same name. One in the framework folder and one in framework/scene_graph/components.

These files are:

camera.cpp
image.cpp
sampler.cpp
hpp_image.cpp

There are two ways to solve this, rename these files so all files in a library is unique or split the library into 2 so within a library the compile unit names are still unique. This PR splits framework into two separate library (framework and framework_scene_graph).

After this issue has been merged we can update the documentation how to generate the Xcode project. eg.

cmake -G Xcode -B build/mac-xcode

Fixes #791

[ ] framework_scene_graph library is compiled using stdcpp14 on windows, other libraries use stdcpp17. we should keep them in sync but I haven been able to find the location where stdcpp17 is set.

General Checklist:

Please ensure the following points are checked:

[x] My code follows the coding style
[x] I have reviewed file licenses
[x] I have commented any added functions (in line with Doxygen)
[x] I have commented any code that could be hard to understand
[x] My changes do not add any new compiler warnings
[x] My changes do not add any new validation layer errors or warnings
[x] I have used existing framework/helper functions where possible
[x] My changes do not add any regressions
[ ] I have tested every sample to ensure everything runs correctly I didn't have access to hardware capable of running all samples.
[x] This PR describes the scope and expected impact of the changes I am making

Note: The Samples CI runs a number of checks including:
- [x] I have updated the header Copyright to reflect the current year (CI build will fail if Copyright is out of date)
- [x] My changes build on Windows, Linux, macOS and Android. Otherwise I have documented any exceptions
- [x] Windows
- [x] Linux
- [x] macOS
- [x] Android

Sample Checklist

If your PR contains a new or modified sample, these further checks must be carried out in addition to the General Checklist:

[NA] I have tested the sample on at least one compliant Vulkan implementation
[NA] If the sample is vendor-specific, I have tagged it appropriately
[NA] I have stated on what implementation the sample has been tested so that others can test on different implementations and platforms
[NA] Any dependent assets have been merged and published in downstream modules
[NA] For new samples, I have added a paragraph with a summary to the appropriate chapter in the readme of the folder that the sample belongs to e.g. api samples readme
[NA] For new samples, I have added a tutorial README.md file to guide users through what they need to know to implement code using this feature. For example, see conditional_rendering
[NA] For new samples, I have added a link to the Antora navigation so that the sample will be listed at the Vulkan documentation site

CLAassistant commented 8 months ago

All committers have signed the CLA.

gpx1000 commented 8 months ago

I fixed this in a different way in the #696. See if that version works for you.

I do like this as a solution as well. The problem with my solution is the names can never conflict, the advantage of this solution is it doesn't matter it will work longer term. Thanks for the submission!

jherico commented 8 months ago

I called out one instance. You need to search your branch for every instance of the string list(APPEND ${ and fix them.

jeroenbakker-atmind commented 8 months ago

@jherico thx for pointing that out. I also detected a logical error where the definitions where used as compile options. I will try to spin on a Windows machine and see how to solve the linker error.

jeroenbakker-atmind commented 8 months ago

@gpx1000 I glanced over your solution (also pointed that one out in the PR description. I wasn't aware of that it was already being addressed. So we need to check which one would be best suited.

My approach is that developers should not become aware of the unique file names issue. In larger applications you typically use prefixes or make the file names unique (by adding the _core as you did). IMO that is less readable for developers as the content of the file doesn't reflect the filename itself. eg the class vbk::core::Image would be easier to find when the file is still called Image.cpp/h.

Anyhow as I am still new to the project I am open for both solutions.

jeroenbakker-atmind commented 8 months ago

Just a note that I had to force push. I saw that one of my machines used a different email address, which made it not possible to accept the CLA. I rewrote the history so one email address was used (for my changes). The other changes (and authors) were kept intact.

gpx1000 commented 8 months ago

@gpx1000 I glanced over your solution (also pointed that one out in the PR description. I wasn't aware of that it was already being addressed. So we need to check which one would be best suited.

My approach is that developers should not become aware of the unique file names issue. In larger applications you typically use prefixes or make the file names unique (by adding the _core as you did). IMO that is less readable for developers as the content of the file doesn't reflect the filename itself. eg the class vbk::core::Image would be easier to find when the file is still called Image.cpp/h.

Anyhow as I am still new to the project I am open for both solutions.

I like your solution more. If we can get this merged ahead of my PR getting merged then I'll back out my changes. Otherwise, I'll create a new PR which reverts the renaming fix. Thanks for the submission. We really appreciate any and all help and this is a good fix.