Discrepancy between raco behavior & docs (5.3.6)

[Josh-Tilles]

According to the raco setup docs, I would have thought that setting $PLT_SETUP_OPTIONS to '--workers 1 pkg1 pkg2 pkg3' would be sufficient to only build & install those three packages. However, I received an error (which I'll reproduce and provide soon) until I added -l, like '--workers 1 -l pkg1 pkg2 pkg3'.

By the way, I know that the presence of --workers 1 is probably immaterial, but until I can verify that it doesn't affect the bug nor the fix, I'll leave it in the problem description.

To make it very clear, the section I'm referring to is:

To restrict raco setup to a set of collections, provide the collection names as arguments. For example, raco setup scribblings/raco would only compile and render the documentation for raco, which is implemented in a "scribblings/raco" collection.

[Josh-Tilles]

With $PLT_SETUP_OPTIONS set to --workers 1 compiler data db dynext ffi file json launcher net openssl pkg planet racket race reader s-exp setup syntax unstable version xml (note that the -l is not yet present), I get the following error:

env CFLAGS="-g -O2   -DOS_X -D_DARWIN_UNLIMITED_SELECT -DXONX  -pthread" LDFLAGS="-pthread"  racket/racket3m -X "/usr/local/Cellar/plt-racket/5.3.6/lib/racket/collects" -N "raco setup" -l- setup --workers 1 compiler data db dynext ffi file json launcher net openssl pkg planet racket raco reader s-exp setup syntax unstable version xml   --no-user --no-docs
raco setup: bootstrapping from source...
open-input-file: cannot open input file
  path: /private/tmp/plt-racket-biba/racket-5.3.6/src/compiler
  system error: No such file or directory; errno=2
  context...:
   /usr/local/Cellar/plt-racket/5.3.6/lib/racket/collects/setup/unpack.rkt:262:2: unpack12
   /usr/local/Cellar/plt-racket/5.3.6/lib/racket/collects/setup/setup-go.rkt: [running body]
   /usr/local/Cellar/plt-racket/5.3.6/lib/racket/collects/setup/main.rkt: [running body]
make[1]: *** [install-3m] Error 1
make: *** [install] Error 2

[Josh-Tilles]

with the -l added to $PLT_SETUP_OPTIONS, I get a different error:

env CFLAGS="-g -O2   -DOS_X -D_DARWIN_UNLIMITED_SELECT -DXONX  -pthread" LDFLAGS="-pthread"  racket/racket3m -X "/usr/local/Cellar/plt-racket/5.3.6/lib/racket/collects" -N "raco setup" -l- setup --workers 1 -l compiler data db dynext ffi file json launcher net openssl pkg planet racket raco reader s-exp setup syntax unstable version xml   --no-user --no-docs
raco setup: bootstrapping from source...
collection-path: collection not found
  collection: "--no-user"
  in collection directories:
   /Users/joshua.tilles/.racket/5.3.6/collects
   /usr/local/Cellar/plt-racket/5.3.6/lib/racket/collects
make[1]: *** [install-3m] Error 1
make: *** [install] Error 2

[Josh-Tilles]

Finally, the installation succeeds if I also apply the following patch:

diff --git a/src/Makefile.in b/src/Makefile.in
index ce4bac4..5d12d25 100644
--- a/src/Makefile.in
+++ b/src/Makefile.in
@@ -62,7 +62,7 @@ both:

 # Install (common) ----------------------------------------

-SETUP_ARGS = -X @DIRCVTPRE@"$(DESTDIR)$(collectsdir)"@DIRCVTPOST@ -N "raco setup" -l- setup $(PLT_SETUP_OPTIONS) $(PLT_ISO) @INSTALL_SETUP_FLAGS@
+SETUP_ARGS = -X @DIRCVTPRE@"$(DESTDIR)$(collectsdir)"@DIRCVTPOST@ -N "raco setup" -l- setup $(PLT_ISO) @INSTALL_SETUP_FLAGS@ $(PLT_SETUP_OPTIONS)

 # Pass compile and link flags to `make install' for use by any
 #  collection-setup actions that compile and link C code:

(it just swaps the order of @INSTALL_SETUP_FLAGS@ and $(PLT_SETUP_OPTIONS))

[Josh-Tilles]

So, I don't know whether I'm crudely working around a deeper bug, or whether the documentation just needs to be updated, or some other alternative.

I'll be happy to help, but at this point it seems like someone knowledgeable with Racket just needs to make a decision about what the intended behavior should be.

[mflatt]

Thanks for your help! I've pushed the patch, plus a related repair so that the -l flag isn't needed.

[Josh-Tilles]

You are entirely welcome!

It's kinduva relief that all that time spent debugging wasn't wasted =P

So, should I close the issue then?

[samth]

On Fri, Oct 25, 2013 at 6:14 PM, MerelyAPseudonym
notifications@github.comwrote:

So, should I close the issue then?

Yes, that would be great.