Comments (11)
The "Xcode" directory structure is actually kind of interesting in some senses.
/Library
- holds pretty much all the content - but no worse than C:\Program Files
/Developer
- possibly superfluous, but differentiates the runtime and developer components
/Toolchains
- this holds the actual toolchains (you may have more than one installed in parallel)
/Platforms
- this holds the actual SDKs (you may have more than one installed in parallel
/Library/Developer/Toolchains/..../usr/bin/
is actually something which makes it slightly easier to deal with inside of the implementation since there are assumptions about the directory structure.
/Library/Developer/Platforms/[Windows|Linux|Android].platform/Developer/SDKs/...
have the SDK content. Especially with some planned work to remove the need for some of the extra flags and have -sdk
take a single location, this makes it somewhat obvious and is why I've been trying to keep that structure.
In reality, this wasn't actually just parroting the Xcode structure, I have given it quite a bit of consideration.
I can see where you are coming from. I would be open to the idea of having an option (preferably marked as advanced) that would let you get an alternative layout which could reside in %ProgramFiles%
.
from swift-build.
Definitely not looking for C:\usr\bin
. I think that we could move the runtime into %ProgramFiles%
though! That way we dont have to have /Library/ICU-64
and can have %ProgramFiles%\ICU-64
for example.
from swift-build.
Taking a name won't work per se, because it doesn't know where to look. I do not wish to add the SDKs into the toolchain directory because I want to have the ability to have multiple Windows SDKs available at once as well as to support multiple architectures.
That does mean that it will need the user to specify the path to the SDK. I think that changing the driver to give it a default search path for the SDK makes sense, or perhaps having it honor SDKROOT
.
Can you explain what you mean by the need for the flags preventing CMake from compiling Swift?
from swift-build.
That can be specified using -DCMAKE_Swift_FLAGS=
. Something like -DCMAKE_Swift_FLAGS="-sdk C:/Library/Developer/Platforms/Windows.platform/Developer/SDKs/Windows.sdk ...
is needed. See the getting started docs or the CI configuration - both of them do this.
from swift-build.
The directory structure we have does have one major problem. As I discovered in #194, the separation of the Swift compiler into C:\Library\Toolchains
and the Swift libraries into C:\Library\Developer\Platforms
makes the Swift compiler choke by default. I must pass the full path to the Windows.sdk directory into every swiftc command line I run for it to work.
I would suggest moving the contents of ā¦\Windows.platform\Developer\SDKs\Windows.sdk\usr
into ā¦\Toolchains\*.xctoolchain\usr
. The Swift compiler should pick them up automatically then. I can prepare a PR if that helps. Thanks!
from swift-build.
Alternatively, do you know how to make swiftc accept a name for the -sdk
parameter instead of an unwieldy full path? Also, the current requirement for an -sdk
path prevents CMake from compiling Swift. This is a major blocker for me.
from swift-build.
If I run CMake on a Swift project, CMake will attempt to compile a "Hello, World"-style program to ensure that the Swift compiler works. Since without the -sdk
flag (which AFAIK cannot be specified at this point in time) the compiler issues the error described in #194. CMake then panics, and refuses to continue configuring the project.
from swift-build.
Coming back to this, trying to figure out what needs to be done. I think that there are two separate issues being discussed here:
- the experience on Windows is rubbish due to the need for the current set of flags which amount to:
-sdk %SystemDrive%\Library\Developer\Platforms\Windows.platform\Developer\SDKs\Windows.sdk
-I %SystemDrive%\Library\Developer\Platforms\Windows.platform\Developer\SDKs\Windows.sdk\usr\lib\windows
-L %SystemDrive%\Library\Developer\Platforms\Windows.platform\Developer\SDKs\Windows.sdk\usr\lib\windows\x86_64
I believe that it should be possible to improve this to:
-sdk %SystemDrive%\Library\Developer\Platforms\Windows.platform\Developer\SDKs\Windows.sdk
However, that is not in the build system but in the compiler.
- The install location is not traditionally Windows.
Moving the locations is certainly possible, but I would like to retain the default to be %SystemDrive%
, and have an option to install to %ProgramFiles%
(as this is 64-bit build, it belongs in %ProgramFiles%
and not %ProgramFiles(x86)%
). Adding an advanced option to change the location is acceptable with the caveat that it does complicate the usage - the space in the path means that quoting must be done properly.
I think that the only thing that makes sense for this repository is the second issue (to which the issue description is relevant).
I'd like to get your opinion on the second one @wjk
from swift-build.
Some better documentation on the layout at https://github.com/compnerd/swift-build/blob/master/docs/Layout.md. @wjk perhaps you can go over it if you have some time? I think that it can be useful to ensure that the document clearly conveys the motivations for the layout.
from swift-build.
Sounds good to me, as long as we don't have C:\usr\bin or anything like that. Also note that WiX can set permissions on the directories it installs. With a bit of research, we can set the ACL on C:\Developer
to be identical to that of C:\Program Files
, and then Iād have no complaints. Thanks!
from swift-build.
We did this for a while, but we now install into a per-user installation instead.
from swift-build.
Related Issues (20)
- Include Yams binaries in the devtools installer HOT 1
- TODO: Add usage instructions of SPM and swiftc HOT 17
- TODO: Update README.md according to the latest build config HOT 2
- Timing HOT 13
- Swift setup cannot create directory error HOT 3
- Manifest parse failure HOT 21
- LinuxMain test issues HOT 2
- error: Error Domain=NSCocoaErrorDomain Code=256 "(null)" HOT 2
- Unable to build using swiftc.exe on Windows 10 out of the box HOT 5
- Linker failure when including outside C header libraries on 5.3-dev HOT 2
- Consider adding a symlink in wix installer for tool_chain_root /usr/lib HOT 3
- swiftWinSDK.dll missing from the toolchain package HOT 2
- Extract CoreFoundation.lib from the build? HOT 3
- swift-build uses the wrong archiver program name on Windows HOT 4
- homogenise the build trees for swfit-corelibs action
- build the stdlib
- build ICU HOT 1
- Manifest parse error under MinGW on Windows HOT 1
- Question about TensorFlow build HOT 8
- Swift release on Windows blocked by Windows Defender HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
š Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. ššš
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ā¤ļø Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from swift-build.