[plt-dev] in-place build directory (was re: build error with svn 14677)

From: Carl Eastlund (carl.eastlund at gmail.com)
Date: Fri May 1 17:34:30 EDT 2009

That doesn't suggest creating a directory called "build" directly
under the "src" directory, nor is that explanation in a prominent
place.  The specific choice of "src/build" is supported by the
svn:ignore property in src/, for instance -- not all choices of build
directory are equal.  And this explanation comes after the initial
description of the "configure" command, despite the need for "mkdir
build" to come before it.  So I think it's somewhat out of order.

For most purposes, someone making a default, in-place build can just
read the first paragraph of each step, maybe skim the rest for
platform-specific "gotchas", and move on.  I know it's important to
read the whole thing, but that doesn't mean everybody will.  I think
those first-paragraphs should spell out a common path to an in-place
build, and currently the "mkdir build ; cd build" step is missing.


On Fri, May 1, 2009 at 5:26 PM, Jay McCarthy <jay.mccarthy at gmail.com> wrote:
> It's already there:
>  The `configure' script generates the makefiles for building
>    MzScheme and/or MrEd. The current directory at the time
>    `configure' is run will be used as working space for building the
>    executables (independent of --prefix). This build directory does
>    not have to be in the source tree, even for an "in-place"
>    build. It's ok to run `configure' from its own directory (as in
>    the example above), but it's often better to pick a separate build
>    directory that is otherwise empty.
> Jay
> On Fri, May 1, 2009 at 3:17 PM, Carl Eastlund <carl.eastlund at gmail.com> wrote:
>> Can we please add this advice to the src/README file?  There are so
>> many esoteric options explained in there, but the one thing that
>> doesn't show up is our convention of creating the src/build/ directory
>> for in-place builds.  New developers shouldn't have to learn this
>> practice by word-of-mouth.
>> This is important enough -- and the README file detailed enough --
>> that we may even want a step between the current 0 (remove old PLT
>> installation) and 1 (run configure) for creating/choosing a build
>> directory, including a default suggestion of src/build/ and followed
>> up by some of the discussion currently under configure.  Otherwise
>> users trying for a "quick-start in-place build" may miss the
>> discussion currently buried at the end of the "configure" section.
>> --Carl
>> ---------- Forwarded message ----------
>> From: Eli Barzilay <eli at barzilay.org>
>> Date: Fri, May 1, 2009 at 5:07 PM
>> Subject: Re: [plt-scheme] build error with svn 14677
>> To: Robby Findler <robby at eecs.northwestern.edu>
>> Cc: Doug Orleans <dougorleans at gmail.com>, plt-scheme at list.cs.brown.edu
>> On May  1, Robby Findler wrote:
>>> The svn tree is the latest, but the Makefiles are not guaranteed to
>>> always get the right dependencies. They usually work, but if you see
>>> problems, best thing is to just blow away the build directory and
>>> try again. (And if you see a configure script change or a
>>> Makefile.in changes, then probably best to not even try.)
>> Right.  To make it *much* better, you should never build the source
>> tree in place -- that is, don't do this:
>>  cd .../plt/src
>>  ./configure
>>  make
>>  make install
>> Do this instead:
>>  cd .../plt/src
>>  mkdir build
>>  cd build
>>  ../configure
>>  make
>>  make install
>> This point is not specific to PLT -- it's generally healthier to do
>> this for any autoconf-based build.
>> --
>>          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
>>                  http://www.barzilay.org/                 Maze is Life!
>> _________________________________________________
>>  For list-related administrative tasks:
>>  http://list.cs.brown.edu/mailman/listinfo/plt-dev
> --
> Jay McCarthy <jay at cs.byu.edu>
> Assistant Professor / Brigham Young University
> http://teammccarthy.org/jay
> "The glory of God is Intelligence" - D&C 93

Posted on the dev mailing list.