Hi,
We have merged a CMake and build-script refactoring that requires a
from-scratch build. Trying to use an existing build directory will
result in strange errors in the middle of the build.
Excuse me for the inconvenience.
Dmitri
--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/
This seems to have broken Xcode project generation, which in the default configuration now fails with:
On May 31, 2016, at 9:37 AM, Dmitri Gribenko via swift-dev <swift-dev@swift.org> wrote:
Hi,
We have merged a CMake and build-script refactoring that requires a
from-scratch build. Trying to use an existing build directory will
result in strange errors in the middle of the build.Excuse me for the inconvenience.
--
CMake Error at CMakeLists.txt:702 (message):
Unknown SDKs:
IOS;IOS_SIMULATOR;TVOS;TVOS_SIMULATOR;WATCHOS;WATCHOS_SIMULATOR
Probably easy to work around by manually configuring out those SDKs, since Xcode projects don't support cross-building to begin with, but this used to just work.
-Joe
New build-script also appears to pass some CMake variables that aren't used in the ninja configuration:
-- Generating done
CMake Warning:
Manually-specified variables were not used by the project:
SWIFT_BUILD_EXAMPLES
SWIFT_HOST_TRIPLE
-Joe
On May 31, 2016, at 10:20 AM, Joe Groff via swift-dev <swift-dev@swift.org> wrote:
On May 31, 2016, at 9:37 AM, Dmitri Gribenko via swift-dev <swift-dev@swift.org> wrote:
Hi,
We have merged a CMake and build-script refactoring that requires a
from-scratch build. Trying to use an existing build directory will
result in strange errors in the middle of the build.Excuse me for the inconvenience.
This seems to have broken Xcode project generation, which in the default configuration now fails with:
--
CMake Error at CMakeLists.txt:702 (message):
Unknown SDKs:
IOS;IOS_SIMULATOR;TVOS;TVOS_SIMULATOR;WATCHOS;WATCHOS_SIMULATORProbably easy to work around by manually configuring out those SDKs, since Xcode projects don't support cross-building to begin with, but this used to just work.
Should be fixed now, sorry for the disruption.
Dmitri
On Tue, May 31, 2016 at 10:20 AM, Joe Groff <jgroff@apple.com> wrote:
On May 31, 2016, at 9:37 AM, Dmitri Gribenko via swift-dev <swift-dev@swift.org> wrote:
Hi,
We have merged a CMake and build-script refactoring that requires a
from-scratch build. Trying to use an existing build directory will
result in strange errors in the middle of the build.Excuse me for the inconvenience.
This seems to have broken Xcode project generation, which in the default configuration now fails with:
--
CMake Error at CMakeLists.txt:702 (message):
Unknown SDKs:
IOS;IOS_SIMULATOR;TVOS;TVOS_SIMULATOR;WATCHOS;WATCHOS_SIMULATORProbably easy to work around by manually configuring out those SDKs, since Xcode projects don't support cross-building to begin with, but this used to just work.
--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/
Hello,
I'm still seeing errors when I try invoking the build script with `-x`.
I've updated all the repositories (everything that lives alongside the
'swift' repo, as well as that repo itself) and deleted my build folder
completely.
I see the following errors multiple times before the build terminates:
"CMake Error at cmake/modules/AddSwift.cmake:578 (add_library):
OBJECT library "swiftRuntime-macosx-x86_64" contains:
RuntimeFunctions.def
but may contain only sources that compile, header files, and other files
that would not affect linking of a normal library.
Call Stack (most recent call first):
cmake/modules/AddSwift.cmake:1159 (_add_swift_library_single)
stdlib/public/runtime/CMakeLists.txt:68 (add_swift_library)"
Am I doing something wrong?
Thanks,
Austin
On Tue, May 31, 2016 at 12:30 PM, Dmitri Gribenko via swift-dev < swift-dev@swift.org> wrote:
On Tue, May 31, 2016 at 10:20 AM, Joe Groff <jgroff@apple.com> wrote:
>
>> On May 31, 2016, at 9:37 AM, Dmitri Gribenko via swift-dev < > swift-dev@swift.org> wrote:
>>
>> Hi,
>>
>> We have merged a CMake and build-script refactoring that requires a
>> from-scratch build. Trying to use an existing build directory will
>> result in strange errors in the middle of the build.
>>
>> Excuse me for the inconvenience.
>
> This seems to have broken Xcode project generation, which in the default
configuration now fails with:
>
> --
> CMake Error at CMakeLists.txt:702 (message):
> Unknown SDKs:
> IOS;IOS_SIMULATOR;TVOS;TVOS_SIMULATOR;WATCHOS;WATCHOS_SIMULATOR
>
> Probably easy to work around by manually configuring out those SDKs,
since Xcode projects don't support cross-building to begin with, but this
used to just work.Should be fixed now, sorry for the disruption.
CMake: more reliably disable cross-compilation in Xcode · apple/swift@d53b5b2 · GitHub
Dmitri
--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
I’ll have a look in to the SWIFT_BUILD_EXAMPLES warning.
SWIFT_HOST_TRIPLE is a new flag used to override the triple we calculate in CMake (for Linux targets only, Darwin SDK configuration is too different right now). I would like it to one day replace SWIFT_HOST_VARIANT_ARCH and SWIFT_HOST_VARIANT_SDK (which will instead by derived from the triple). We will need SDKs to become architecture-specific at some point (so that we don’t need to hardcode ‘ANDROID’ as ‘armv7’, or so that you can compile multiple architecture variants of the same SDK such as ‘linux-i386’ and ‘linux-x86_64’), and we’re going to need to calculate triples for them, so it just makes sense to do the triple calculation in the build script and use them in place of SDK names to configure both the host and stdlib targets.
So that means instead of using these flags to configure swift:
- SWIFT_HOST_VARIANT_SDK (e.g. LINUX)
- SWIFT_HOST_VARIANT_ARCH (e.g. x86_64)
- SWIFT_SDKS (e.g. LINUX;ANDROID)
We’d configure it like this:
- SWIFT_HOST_TRIPLE (e.g x86_64-unknown-linux-gnu)
- SWIFT_DEPLOYMENT_TARGETS (e.g. x86_64-unknown-linux-gnu + armv7-linux-gnueabihf + armv7-none-linux-androideabi + i386-none-linux-androideabi + …)
(+ SWIFT_{platform}_{arch}_SYSROOT for all non-Darwin targets except host, but that’s new functionality)
I didn't want to change too much too quickly, but if we’re happy with this direction, I can do the triple->HOST_VARIANT_SDK/ARCH part for all platforms which would silence the warning. We’d still configure by SDK names and hardcoded architectures. Changing that part is less simple.
This was obviously a big patch and I apologise if it caused any problems. If there’s anything else I can help with please let me know.
On the other hand, that’s pretty much all we had to do to compile foreign hosts. The rest is tiny and fairly uncontroversial (https://github.com/karwa/swift/commit/d090724bd37dffe243d477fd0ffd1ba87a90c70b\).
Karl
On 31 May 2016, at 19:49, Joe Groff via swift-dev <swift-dev@swift.org> wrote:
On May 31, 2016, at 10:20 AM, Joe Groff via swift-dev <swift-dev@swift.org> wrote:
On May 31, 2016, at 9:37 AM, Dmitri Gribenko via swift-dev <swift-dev@swift.org> wrote:
Hi,
We have merged a CMake and build-script refactoring that requires a
from-scratch build. Trying to use an existing build directory will
result in strange errors in the middle of the build.Excuse me for the inconvenience.
This seems to have broken Xcode project generation, which in the default configuration now fails with:
--
CMake Error at CMakeLists.txt:702 (message):
Unknown SDKs:
IOS;IOS_SIMULATOR;TVOS;TVOS_SIMULATOR;WATCHOS;WATCHOS_SIMULATORProbably easy to work around by manually configuring out those SDKs, since Xcode projects don't support cross-building to begin with, but this used to just work.
New build-script also appears to pass some CMake variables that aren't used in the ninja configuration:
-- Generating done
CMake Warning:
Manually-specified variables were not used by the project:
SWIFT_BUILD_EXAMPLES
SWIFT_HOST_TRIPLE-Joe
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
Hi Karl,
One thing to keep in mind is that triples are not as useful as they
can seem to be, and trying to derive information from them can
sometimes be a futile exercise because the information just either
isn't there, or different vendors mean different things but use the
same triple.
This is an excellent thread on this topic from llvm-dev:
http://comments.gmane.org/gmane.comp.compilers.llvm.devel/87804
Also: Multiarch/Tuples - Debian Wiki
I'm not saying that SDK/ARCH is a better replacement (it isn't, it is
currently a strict subset of the information from the triple), but at
least it is not the triple itself, so people don't have the
expectation of being able to provide the triple and let the system
figure out the rest. So I'd be concerned about starting to treat the
triple as the primary piece of information, and the rest as secondary.
Dmitri
On Wed, Jun 1, 2016 at 7:17 AM, Karl via swift-dev <swift-dev@swift.org> wrote:
We’d configure it like this:
- SWIFT_HOST_TRIPLE (e.g x86_64-unknown-linux-gnu)
- SWIFT_DEPLOYMENT_TARGETS (e.g. x86_64-unknown-linux-gnu + armv7-linux-gnueabihf + armv7-none-linux-androideabi + i386-none-linux-androideabi + …)
--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/
Yes, I’m not really fond of using triples either. However, we need the triple for every stdlib target we build anyway, so even if we passed some kind of list of tuples from build-script > CMake, we’d have to try and derive a triple from that information and it must always match the thing that was specified in the build-script to configure LLVM.
The build script still only works in terms of “deployment targets” (e.g. iphoneos-armv7, iphonesimulator-x86_64) and the triples are hardcoded in there, so it’s not like we expect CMake to just work with completely arbitrary triples. The host and all of the stdlib targets you build will come from that curated list of triples which we know can be detected.
We don’t need too much information, anyway. We only need the architecture, and enough pattern matching to disambiguate which SDK it’s referring to (e.g match “*-linux-gnu*" for linux, “*-linux-android*" for android, etc). We don’t really need to *completely* understand the triple.
@Austin: Could your issues be related to Merge pull request #2809 from apple/cmake-use-object-libraries · apple/swift@06d8455 · GitHub ?
Karl
On 1 Jun 2016, at 18:16, Dmitri Gribenko <gribozavr@gmail.com> wrote:
On Wed, Jun 1, 2016 at 7:17 AM, Karl via swift-dev <swift-dev@swift.org> wrote:
We’d configure it like this:
- SWIFT_HOST_TRIPLE (e.g x86_64-unknown-linux-gnu)
- SWIFT_DEPLOYMENT_TARGETS (e.g. x86_64-unknown-linux-gnu + armv7-linux-gnueabihf + armv7-none-linux-androideabi + i386-none-linux-androideabi + …)Hi Karl,
One thing to keep in mind is that triples are not as useful as they
can seem to be, and trying to derive information from them can
sometimes be a futile exercise because the information just either
isn't there, or different vendors mean different things but use the
same triple.This is an excellent thread on this topic from llvm-dev:
http://comments.gmane.org/gmane.comp.compilers.llvm.devel/87804
Also: Multiarch/Tuples - Debian Wiki
I'm not saying that SDK/ARCH is a better replacement (it isn't, it is
currently a strict subset of the information from the triple), but at
least it is not the triple itself, so people don't have the
expectation of being able to provide the triple and let the system
figure out the rest. So I'd be concerned about starting to treat the
triple as the primary piece of information, and the rest as secondary.Dmitri
--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/
Hi Austin,
I'm sorry for the breakage. This issue should be fixed by
https://github.com/apple/swift/pull/2840\.
Dmitri
On Wed, Jun 1, 2016 at 12:36 PM, Austin Zheng <austinzheng@gmail.com> wrote:
Hello,
I'm still seeing errors when I try invoking the build script with `-x`. I've
updated all the repositories (everything that lives alongside the 'swift'
repo, as well as that repo itself) and deleted my build folder completely.I see the following errors multiple times before the build terminates:
"CMake Error at cmake/modules/AddSwift.cmake:578 (add_library):
OBJECT library "swiftRuntime-macosx-x86_64" contains:RuntimeFunctions.def
--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/
It works now. Thanks for fixing it so quickly!
Austin
On Thu, Jun 2, 2016 at 2:00 PM, Dmitri Gribenko <gribozavr@gmail.com> wrote:
On Wed, Jun 1, 2016 at 12:36 PM, Austin Zheng <austinzheng@gmail.com> > wrote:
> Hello,
>
> I'm still seeing errors when I try invoking the build script with `-x`.
I've
> updated all the repositories (everything that lives alongside the 'swift'
> repo, as well as that repo itself) and deleted my build folder
completely.
>
> I see the following errors multiple times before the build terminates:
>
> "CMake Error at cmake/modules/AddSwift.cmake:578 (add_library):
> OBJECT library "swiftRuntime-macosx-x86_64" contains:
>
> RuntimeFunctions.defHi Austin,
I'm sorry for the breakage. This issue should be fixed by
https://github.com/apple/swift/pull/2840\.Dmitri
--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/