[racket-dev] Building HEAD today

From: Matthew Flatt (mflatt at cs.utah.edu)
Date: Wed Jul 17 17:23:25 EDT 2013

At Wed, 17 Jul 2013 16:48:06 -0400, Greg Hendershott wrote:
> I did my first fetch and build of HEAD today, using the new layout. A
> few surprises; I wanted to ask if they're as-expected (at least at
> this point in the change to the new approach).
> 
> If the short answer is, "Please go away and try again later after
> things have settled down" then no worries. :)

Please *do not* go away and wait until later. Things are supposed to
work.

> 0. I simply ran `make' from the project's top dir (on OS X in case
> that matters).

Good.

> 1. I notice the `racket' command-line binary moved from bin/racket to
> racket/bin/racket -- correct?  (Not complaining, don't mind adjusting
> my PATH. Just checking it's as-expected.)

Yes, that's as expected.


> 2. When I run bin/racket/racket, it says
> 
> "Welcome to Racket v5.3.900.7."
> 
> Um, aren't we past 5.3.5? Did I do something wrong?

It gets difficult to read with that many dots, but version 5.3.900.7 is
past version 5.3.5 (since 900 is past 5). We'll eventually switch to
5.900.x (and probably should have already).


> 3. During build I got this error:

It looks like the "release.scrbl" document, which assembles release
notes, does not protect against an "info.rkt" file that has a
`release-notes' definition that is not a string.

More specifically, I think the problem is that `release-notes' is used
for PLaneT packages, in which case it's an X-expr instead of a string.

I'll change/fix "release.scrbl" to avoid the collision. (Also, I think
that documenting the new "info.rkt" field for release notes is still on
my todo list.)


> 4. I got many "re-rendering" lines:

That's the new normal, unfortunately. I think there must be a better
way to order the builds --- and it turns out that `-j 1' mode is
ordered better --- but that is future work for now.

You didn't see "re-rendering" so much in the old version, but mainly
because dependency tracking was broken, as it turns out.


> 5. At the end, I got many, many lines about dependency checking for
> packages with dev links:
> 
> raco setup: found undeclared dependency:
> raco setup:   mode: run
> raco setup:   for package: "frog"
> raco setup:   on package: core
> raco setup:   dependent source: config_rkt.zo
> raco setup:   used module: (lib "racket/syntax.rkt")
> [...]
> 
> Is this normal (or normal for the time being, and OK to ignore)?

Now that the Racket distribution is composed of many packages, your
package depends on many packages. Ideally, you'd add in all those
dependencies.

Unfortunately, if you add in the dependencies, then your package won't
work with v5.3.6 and earlier, because the packages don't exist for that
distribution.

We need to sort this out, and I'll bump it to the top of the list.
(Probably, we need to add "main-distribution" as a package for v5.3.6
and earlier, or something like that.) Meanwhile, you can ignore the
errors.


> 6. The very end of the build looked like this:
> 
> raco setup: found undeclared dependency:
> raco setup:   mode: run
> raco setup:   for package: "frog"
> raco setup:   on package: core
> raco setup:   dependent source: frog_rkt.zo
> raco setup:   used module: (lib "frog/frog")
> combine-relative-elements: relative path escapes collection: (up
> #<path:info.rkt>) relative to (lib "frog" "frog")
>   context...:

I recently (June 6) wrote to you

 Using a relative path "../info.rkt" that steps outside a collection
 feels wrong, but I don't have a concrete reason or better idea.

Now we have a concrete reason, so we'll have to find a better idea.


> 7. After the build, Git prompts me about a new untracked file:
> 
> git status
> # On branch master
> # Untracked files:
> #   (use "git add <file>..." to include in what will be committed)
> #
> #    
> pkgs/racket-pkgs/racket-test/tests/racket/benchmarks/places/place-benchmark13740
> 909571374090957150.rkt
> nothing added to commit but untracked files present (use "git add" to track)
> 
> If I want to stay in clean sync with upstream, should I .gitignore
> that or add it?

Delete that file. I'll figure out what's generating it and fix it.


Posted on the dev mailing list.