DragonFlyBSD / DPorts

The dedicated application build system for DragonFly BSD
Other
89 stars 44 forks source link

Add port for rust-devel 1.0.0.20150128 #134

Closed mneumann closed 9 years ago

jrmarino commented 9 years ago

I saw the pull request last night and started working on it. My current work version is here: https://github.com/DragonFlyBSD/DeltaPorts/tree/master/ports/lang/rust-dragonfly/newport

I renamed it "rust-dragonfly" because there's a decent chance "rust-devel" could appear in ports and I want to avoid a clash before it happens.

I had to rearrange the Makefile (significantly) to make portlint happy.

Currently, the build fails. I think it's missing listed dependencies, specifically I think "curl" is a build dependency:

===>  Configuring for rust-1.0.0.20150128
configure: looking for configure programs
configure: found program cmp
configure: found program mkdir
configure: found program printf
configure: found program cut
configure: found program head
configure: found program grep
configure: found program xargs
configure: found program cp
configure: found program find
configure: found program uname
configure: found program date
configure: found program tr
configure: found program sed
configure: found program file
configure: found program make
configure: inspecting environment
configure: recreating config.tmp
configure: 
configure: processing ./configure args
configure: 
configure: CFG_DISABLE_DOCS     := 1 
configure: CFG_LOCALSTATEDIR    := /var/lib 
configure: CFG_SYSCONFDIR       := /etc 
configure: CFG_DATADIR          := /share 
configure: CFG_INFODIR          := /share/info 
configure: CFG_LLVM_ROOT        :=  
configure: CFG_JEMALLOC_ROOT    :=  
configure: CFG_BUILD            := x86_64-unknown-dragonfly 
configure: CFG_ANDROID_CROSS_PATH := /opt/ndk_standalone 
configure: CFG_BUILD            := x86_64-unknown-dragonfly 
configure: CFG_LIBDIR           := /usr/local/lib 
configure: 
configure: validating ./configure args
configure: 
configure: CFG_RELEASE_CHANNEL  := dev 
configure: CFG_BOOTSTRAP_KEY    := 11:02:34 
configure: 
configure: looking for build programs
configure: 
configure: CFG_CURLORWGET       :=  
configure: error: needed, but unable to find any of: CFG_CURLORWGET curl wget
===>  Script "configure" failed unexpectedly.
Please report the problem to mneumann@ntecs.de [maintainer] and attach the
"/wrkdirs/lang/rust-dragonfly/work/rustc-nightly/config.log" including the
output of the failure of your make command. Also, it might be a good idea to
provide an overview of all packages installed on your system (e.g. a
/usr/local/sbin/pkg-static info -g -Ea).

I'll try adding it. (This is a good illustration of the value of poudriere for new ports development)

jrmarino commented 9 years ago

Adding curl as build dependency worked, but it failed during build. looking at that now to see if my changes caused it.

cd "x86_64-unknown-dragonfly/rt/jemalloc"; "/wrkdirs/lang/rust-dragonfly/work/rustc-nightly/src/jemalloc/configure"  --with-jemalloc-prefix=je_ --disable-fill  --build=x86_64-unknown-dragonfly --host=x86_64-unknown-dragonfly CC="cc -m64 -I/usr/include -I/usr/local/include -pipe -O2 -fno-strict-aliasing" AR="ar" RANLIB="ar s" CPPFLAGS="-I /wrkdirs/lang/rust-dragonfly/work/rustc-nightly/src/rt/" EXTRA_CFLAGS="-g1 -ffunction-sections -fdata-sections"
gmake[2]: Entering directory '/wrkdirs/lang/rust-dragonfly/work/rustc-nightly/src/compiler-rt'
compile: x86_64-unknown-dragonfly/rt/rust_builtin.o
opening snapshot /portdistfiles/rust/rust-stage0-2015-01-20-9006c3c-dragonfly-x86_64-0bb1d3eedbcd0b36ab01e4ac0539fb8a393c348d.tar.bz2
Traceback (most recent call last):
  File "/wrkdirs/lang/rust-dragonfly/work/rustc-nightly/src/etc/get-snapshot.py", line 70, in <module>
    unpack_snapshot(triple, dl_path)
  File "/wrkdirs/lang/rust-dragonfly/work/rustc-nightly/src/etc/get-snapshot.py", line 18, in unpack_snapshot
    tar = tarfile.open(dl_path)
  File "/usr/local/lib/python2.7/tarfile.py", line 1666, in open
    return func(name, "r", fileobj, **kwargs)
  File "/usr/local/lib/python2.7/tarfile.py", line 1731, in gzopen
    fileobj = gzip.GzipFile(name, mode, compresslevel, fileobj)
  File "/usr/local/lib/python2.7/gzip.py", line 94, in __init__
    fileobj = self.myfileobj = __builtin__.open(filename, mode or 'rb')
IOError: [Errno 2] No such file or directory: '/portdistfiles/rust/rust-stage0-2015-01-20-9006c3c-dragonfly-x86_64-0bb1d3eedbcd0b36ab01e4ac0539fb8a393c348d.tar.bz2'
make: cleaning llvm
/wrkdirs/lang/rust-dragonfly/work/rustc-nightly/mk/stage0.mk:17: recipe for target 'x86_64-unknown-dragonfly/stage0/bin/rustc' failed
jrmarino commented 9 years ago

probably this line: "MAKE_ENV= SNAPSHOT_FILE=${DISTDIR}/${PORTNAME}/${RUST_BOOT}"

This is why I systematically remove ${PORTNAME} and always use hardcoded values. Not always, but most of the time the port breaks if the portname changes where a hard-coded versions doesn't.

jrmarino commented 9 years ago

using DIST_SUBDIR instead of PORTNAME fixes it properly I suspect

jrmarino commented 9 years ago

Either rustc spends minutes on a single file or the build is stuck: http://muscles.dragonflybsd.org/bulk/bleeding-edge-potential/20150203_032546/logs/rust-1.0.0.20150128.log

load is relatively low (~1 - 2) but top -M says one CPU is 100%

jrmarino commented 9 years ago

I'm stopping the build. I hasn't moved in 20 minutes at least.

jrmarino commented 9 years ago

hmm. I haven't stopped it yet. the (rustc) process is changing pids and the loaded CPU changed IDs. Something is going on but the log is stuck. (it appears)

jrmarino commented 9 years ago

Michael, is it possible this port is not jobs safe?
dports will use multi-job by default, and I assume your machine has more than one CPU, but rust keeps building the same files. I don't know if this is normal or not but it looks crazy to me. the log is slowly changing but with previously built source files.

jrmarino commented 9 years ago

the build eventually "ran away" and when poudriere tried to clean up. thousands of processes were spawned (the makefile received an error and ran again rather than aborted, continuously, forever). Very dangerous -- that needs to be fixed even it's a problem with rust makefile itself.

jrmarino commented 9 years ago

it's possible this line caused the runaway:

check: build
    @(cd ${WRKSRC} && ${SETENV} ${MAKE_ENV} \
        ${MAKE_CMD} ${_MAKE_JOBS} ${MAKE_ARGS} check)

maybe check is always executed after build, which requires build and thus if the build was not successful it would run in a cycle. There were at least 5000 "Please make check to run regression tests" echos listed in ps, so it was running post-build over and over. I'm going to rename that target so it's not automatically run, at least for now. (it's not on lang/rust makefile either)

jrmarino commented 9 years ago

okay, the "check" target was definitely getting run. I've disabled it and added "VERBOSE=1" to MAKE_ARGS when built by poudriere. a build is currently going on here:

http://muscles.dragonflybsd.org/bulk/bleeding-edge-potential/20150203_071131/logs/rust-1.0.0.20150128.log

Notice that building occurs after the build stage, in the "prestage" target. It should only be installing in these targets. If the lang/rust port does this, it's also wrong. All building should be restricted to the build stage.

jrmarino commented 9 years ago

It actually finished with "check" target disabled. However, it failed QA checks:

====> Running Q/A tests (stage-qa)
Error: 'lib/rustlib/manifest-rustc' is referring to /wrkdirs/lang/rust-dragonfly
/work/stage
*** Error code 1

Stop.
make: stopped in /usr/ports/lang/rust-dragonfly
=> Error: stage-qa failures detected
build of lang/rust-dragonfly ended at Tue Feb  3 08:42:59 PST 2015
build time: 01:31:25
!!! build failure encountered !!!
01:31:28 => Error: Build failed in phase: stage-qa
01:31:28 => Cleaning up
01:31:28 => Umounting file systems
jrmarino commented 9 years ago

okay, I fixed all the problems, here: f8b9def6e31eede064cf82a5513118a5885de392 It will not run "check" by default in poudriere. In fact, I changed the target name to "regression-test"

The building part of install now occurs in post-build so "make install" only installs now as it should. anyway, the port is in dports now and will probably be in the packages repo within 2 days.