Hi,
I built swift for Linux(openSUSE 13.2) from source code, by
"./utils/build-script -R" command.
It works for run test.swift file, but can not run on REPL mode,
the error message is:
"LLVM ERROR: Compiler-internal integrated REPL unimplemented for this
platform; use the LLDB-enhanced REPL instead."
since I always failed to build for Debug mode, I need some help to run
REPL,
Thanks.
ccw
Hi Thomas,
To run the REPL, the 'swift' and 'lldb' binaries need to be next to
each other. This is not the case in the build tree. Either create a
symlink, or build the package using 'build-script
--preset=buildbot_linux_1404 installable_package=/tmp/swift.tar.gz
install_destdir=/tmp/swift-install', and try again from the package.
Dmitri
On Sun, Dec 6, 2015 at 12:10 AM, Thomas# Chiang via swift-users <swift-users@swift.org> wrote:
Hi,
I built swift for Linux(openSUSE 13.2) from source code, by "./utils/build-script -R" command.
It works for run test.swift file, but can not run on REPL mode,
the error message is:
"LLVM ERROR: Compiler-internal integrated REPL unimplemented for this platform; use the LLDB-enhanced REPL instead."since I always failed to build for Debug mode, I need some help to run REPL,
--
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>*/
Dmitri, this seems to be a common problem. What would you think about creating symlinks in the build tree (when building the appropriate projects), just to smooth over the development process?
- Daniel
On Dec 6, 2015, at 12:14 AM, Dmitri Gribenko via swift-users <swift-users@swift.org> wrote:
On Sun, Dec 6, 2015 at 12:10 AM, Thomas# Chiang via swift-users > <swift-users@swift.org> wrote:
Hi,
I built swift for Linux(openSUSE 13.2) from source code, by "./utils/build-script -R" command.
It works for run test.swift file, but can not run on REPL mode,
the error message is:
"LLVM ERROR: Compiler-internal integrated REPL unimplemented for this platform; use the LLDB-enhanced REPL instead."since I always failed to build for Debug mode, I need some help to run REPL,
Hi Thomas,
To run the REPL, the 'swift' and 'lldb' binaries need to be next to
each other. This is not the case in the build tree. Either create a
symlink, or build the package using 'build-script
--preset=buildbot_linux_1404 installable_package=/tmp/swift.tar.gz
install_destdir=/tmp/swift-install', and try again from the package.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-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
I also hit this problem.
I compiled like so: ./swift/utils/build-script --lldb
I created a new directory to house the symlinks:
$ mkdir mybins; cd mybins
I created symlinks:
$ for i in $(ls -1 ../build/Ninja-DebugAssert/llvm-linux-x86_64/bin/*); do
ln -s $i; done
$ for i in $(ls -1 ../build/Ninja-DebugAssert/swift-linux-x86_64/bin/*); do
ln -s $i; done
$ for i in $(ls -1 ../build/Ninja-DebugAssert/lldb-linux-x86_64/bin/*); do
ln -s $i; done
So now there are symlinks in the same directory for lldb and swift.
$ ./swift
LLVM ERROR: Compiler-internal integrated REPL unimplemented for this
platform; use the LLDB-enhanced REPL instead.
And I still get the error. Any thoughts?
Thanks,
Lane
>
> Hi,
>
> I built swift for Linux(openSUSE 13.2) from source code, by
"./utils/build-script -R" command.
> It works for run test.swift file, but can not run on REPL mode,
> the error message is:
> "LLVM ERROR: Compiler-internal integrated REPL unimplemented for this
platform; use the LLDB-enhanced REPL instead."
>
> since I always failed to build for Debug mode, I need some help to run
REPL,
On Sun, Dec 6, 2015 at 2:14 AM, Dmitri Gribenko via swift-users < swift-users@swift.org> wrote:
On Sun, Dec 6, 2015 at 12:10 AM, Thomas# Chiang via swift-users > <swift-users@swift.org> wrote:
Hi Thomas,
To run the REPL, the 'swift' and 'lldb' binaries need to be next to
each other. This is not the case in the build tree. Either create a
symlink, or build the package using 'build-script
--preset=buildbot_linux_1404 installable_package=/tmp/swift.tar.gz
install_destdir=/tmp/swift-install', and try again from the package.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-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
--
When a place gets crowded enough to require ID's, social collapse is not
far away. It is time to go elsewhere. The best thing about space travel
is that it made it possible to go elsewhere.
-- R.A. Heinlein, "Time Enough For Love"
Actually, I am retracting this suggestion in favor of what I think is a better one:
What if we change the build process to build up a "composed package" as part of the regular build. We would clear this at the start of each build, and then build up the installed compiler + libraries + package manager as each project completed its build (basically just using the same install logic into a side location).
This has a number of benefits:
- At the end of the build, we have a "build/<config>/bin" directory which has a functioning compiler.
- Each project in the chain can use the composed build to work with. So for example, the package manager can build with the compiler + xctest as they are expected to look in a package. This would reduce some complexity in our build process, and be more maintainable.
- This solution scales better if/when we add more projects.
- This solution also lets the build easily sub in an "prebuilt package" into the build process (it just means pointing at a different composed package).
Thoughts?
- Daniel
On Dec 10, 2015, at 8:43 AM, Daniel Dunbar <daniel_dunbar@apple.com> wrote:
Dmitri, this seems to be a common problem. What would you think about creating symlinks in the build tree (when building the appropriate projects), just to smooth over the development process?
- Daniel
On Dec 6, 2015, at 12:14 AM, Dmitri Gribenko via swift-users <swift-users@swift.org> wrote:
On Sun, Dec 6, 2015 at 12:10 AM, Thomas# Chiang via swift-users >> <swift-users@swift.org> wrote:
Hi,
I built swift for Linux(openSUSE 13.2) from source code, by "./utils/build-script -R" command.
It works for run test.swift file, but can not run on REPL mode,
the error message is:
"LLVM ERROR: Compiler-internal integrated REPL unimplemented for this platform; use the LLDB-enhanced REPL instead."since I always failed to build for Debug mode, I need some help to run REPL,
Hi Thomas,
To run the REPL, the 'swift' and 'lldb' binaries need to be next to
each other. This is not the case in the build tree. Either create a
symlink, or build the package using 'build-script
--preset=buildbot_linux_1404 installable_package=/tmp/swift.tar.gz
install_destdir=/tmp/swift-install', and try again from the package.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-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
My concern is that copying files around will significantly increase
the build time for everyone because of I/O. Debug builds of Swift are
quite large (> 700 Mb IIRC).
Dmitri
On Thu, Dec 10, 2015 at 9:59 AM, Daniel Dunbar <daniel_dunbar@apple.com> wrote:
Actually, I am retracting this suggestion in favor of what I think is a better one:
What if we change the build process to build up a "composed package" as part of the regular build. We would clear this at the start of each build, and then build up the installed compiler + libraries + package manager as each project completed its build (basically just using the same install logic into a side location).
This has a number of benefits:
- At the end of the build, we have a "build/<config>/bin" directory which has a functioning compiler.
- Each project in the chain can use the composed build to work with. So for example, the package manager can build with the compiler + xctest as they are expected to look in a package. This would reduce some complexity in our build process, and be more maintainable.
- This solution scales better if/when we add more projects.
- This solution also lets the build easily sub in an "prebuilt package" into the build process (it just means pointing at a different composed package).Thoughts?
--
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>*/
Actually, I am retracting this suggestion in favor of what I think is a better one:
What if we change the build process to build up a "composed package" as part of the regular build. We would clear this at the start of each build, and then build up the installed compiler + libraries + package manager as each project completed its build (basically just using the same install logic into a side location).
This has a number of benefits:
- At the end of the build, we have a "build/<config>/bin" directory which has a functioning compiler.
- Each project in the chain can use the composed build to work with. So for example, the package manager can build with the compiler + xctest as they are expected to look in a package. This would reduce some complexity in our build process, and be more maintainable.
- This solution scales better if/when we add more projects.
- This solution also lets the build easily sub in an "prebuilt package" into the build process (it just means pointing at a different composed package).Thoughts?
My concern is that copying files around will significantly increase
the build time for everyone because of I/O. Debug builds of Swift are
quite large (> 700 Mb IIRC).
My thought here was to use rsync and its options for creating hard links where possible. This makes the copying very cheap...
- Daniel
On Dec 10, 2015, at 11:07 AM, Dmitri Gribenko <gribozavr@gmail.com> wrote:
On Thu, Dec 10, 2015 at 9:59 AM, Daniel Dunbar <daniel_dunbar@apple.com <mailto:daniel_dunbar@apple.com>> wrote:
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 <mailto:gribozavr@gmail.com>>*/
How would you implement it in practice? CMake does not know how to
use rsync for its 'install' target, IIRC.
Dmitri
On Sun, Dec 20, 2015 at 12:03 PM, Daniel Dunbar <daniel_dunbar@apple.com> wrote:
On Dec 10, 2015, at 11:07 AM, Dmitri Gribenko <gribozavr@gmail.com> wrote:
On Thu, Dec 10, 2015 at 9:59 AM, Daniel Dunbar <daniel_dunbar@apple.com> > wrote:
Actually, I am retracting this suggestion in favor of what I think is a
better one:What if we change the build process to build up a "composed package" as part
of the regular build. We would clear this at the start of each build, and
then build up the installed compiler + libraries + package manager as each
project completed its build (basically just using the same install logic
into a side location).This has a number of benefits:
- At the end of the build, we have a "build/<config>/bin" directory which
has a functioning compiler.
- Each project in the chain can use the composed build to work with. So for
example, the package manager can build with the compiler + xctest as they
are expected to look in a package. This would reduce some complexity in our
build process, and be more maintainable.
- This solution scales better if/when we add more projects.
- This solution also lets the build easily sub in an "prebuilt package" into
the build process (it just means pointing at a different composed package).Thoughts?
My concern is that copying files around will significantly increase
the build time for everyone because of I/O. Debug builds of Swift are
quite large (> 700 Mb IIRC).My thought here was to use rsync and its options for creating hard links
where possible. This makes the copying very cheap...
--
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>*/