Problem building racket in-place

[Reuben Thomas]

I have a CONFIG_SITE environment variable which contains the following line:

test "$prefix" = NONE && prefix="$HOME_LOCAL"

(HOME_LOCAL is set to $HOME/.local)

Things then go wrong because racket/src/start/configure.ac code relies on prefix still being set to NONE in order to finally set prefix to `cd "${srcdfir}/.." && pwd`.

Is there some reason that prefix cannot be passed in from the top-level Makefile for an in-place build?

--

https://rrt.sc3d.org

[Matthew Flatt]

I think it would be ok to add `--prefix=NONE` to `CONFIG_IN_PLACE_ARGS`
in the top-level makefile (alongside `--enable-origtree`). Does that
solve the problem?


Matthew

[Reuben Thomas]

Thanks for the suggestion! That doesn't work, because when configure is run, it reads CONFIG_SITE, loads my config file that checks `$prefix = NONE` (it is!), which thus overrides it.

Adding `--prefix=`cd ../.. && pwd` to `CONFIG_IN_PLACE_ARGS` works for setting `prefix`, but of course configure will then fail to set `inplacebuild`, because to do so it tests `${prefix} = "NONE"`. Is there some reason configure can't test `enable_origtree`? Is there some time the build system is supposed to build in-tree even without --enable-origtree? If so, could it test `"${prefix}" = "NONE" -o "${enable_origtree}" = "yes"`?

--

https://rrt.sc3d.org

[Matthew Flatt]

At Tue, 12 Nov 2019 22:47:33 +0000, Reuben Thomas wrote:
> Is there
> some reason configure can't test `enable_origtree`? Is there some time the
> build system is supposed to build in-tree even without --enable-origtree?
> If so, could it test `"${prefix}" = "NONE" -o "${enable_origtree}" = "yes"`?

Unless I misremember, the `--enable-origtree` and `--prefix=` options
are supposed to work together to create an installation at the given
prefix that has the same directory structure as an in-place build. So,
if I understand your question, that's why `--enable-origtree` doesn't
make `prefix` ignored.

Maybe the solution is to add `--disable-prefix` and have the top-level
makefile use that along with `--enable-origtree`?

[Reuben Thomas]

On Wed, 13 Nov 2019 at 13:40, Matthew Flatt <mfl...@cs.utah.edu> wrote:

Maybe the solution is to add `--disable-prefix` and have the top-level
makefile use that along with `--enable-origtree`?

Sounds good to me.

While looking into implementing this, I discovered that `racket/src/start/configure.ac`, which seems to have been introduced with the introduction of CS, is not generated from racket/src/ac/*.m4, while all the other configure.ac's are.

I guess this explains why the fix to `src/ac/path.m4` in commit a56c984db0 (inter alia) has not been applied to `start/configure.ac`?

Since as far as I can tell, the putative `--disable-prefix` needs to be implemented in both `start/configure.ac` and `ac/path{,_arg}.m4`, I thought it was worth sorting this out before trying to attempt the fix.

[I must say that despite having long and even over-zealous experience with autotools hacking (up to and including auto-generating an autoconf and running the generated configure from within a Makefile.am), I am somewhat terrified by the dizzying many-layered depth of Racket's build system, so please forgive any incomprehension in the foregoing.]

--

https://rrt.sc3d.org

[Matthew Flatt]

At Wed, 13 Nov 2019 21:58:24 +0000, "'Reuben Thomas' via Racket Users" wrote:
> While looking into implementing this, I discovered that `racket/src/start/
> configure.ac`, which seems to have been introduced with the introduction of
> CS, is not generated from racket/src/ac/*.m4, while all the other
> configure.ac's are.
>
> I guess this explains why the fix to `src/ac/path.m4` in commit a56c984db0
> (inter alia) has not been applied to `start/configure.ac`?
>
> Since as far as I can tell, the putative `--disable-prefix` needs to be
> implemented in both `start/configure.ac` and `ac/path{,_arg}.m4`, I thought
> it was worth sorting this out before trying to attempt the fix.

Yes, it's definitely a mistake that "start/configure.ac" doesn't use
"src/ac/path.m4". (I must have lost track of that part when creating
"start/configure.ac" and other files out of the old single
"configure.ac".)

A repair for that as part of adding `--disable-prefix` would be very
welcome.

> [I must say that despite having long and even over-zealous experience with
> autotools hacking (up to and including auto-generating an autoconf and
> running the generated configure from within a Makefile.am), I am somewhat
> terrified by the dizzying many-layered depth of Racket's build system, so
> please forgive any incomprehension in the foregoing.]

It's a monster.

[Reuben Thomas]

On Thu, 14 Nov 2019 at 12:51, Matthew Flatt <mfl...@cs.utah.edu> wrote:

At Wed, 13 Nov 2019 21:58:24 +0000, "'Reuben Thomas' via Racket Users" wrote:
> While looking into implementing this, I discovered that `racket/src/start/
> configure.ac`, which seems to have been introduced with the introduction of
> CS, is not generated from racket/src/ac/*.m4, while all the other
> configure.ac's are.
>
> I guess this explains why the fix to `src/ac/path.m4` in commit a56c984db0
> (inter alia) has not been applied to `start/configure.ac`?
>
> Since as far as I can tell, the putative `--disable-prefix` needs to be
> implemented in both `start/configure.ac` and `ac/path{,_arg}.m4`, I thought
> it was worth sorting this out before trying to attempt the fix.

Yes, it's definitely a mistake that "start/configure.ac" doesn't use
"src/ac/path.m4". (I must have lost track of that part when creating
"start/configure.ac" and other files out of the old single
"configure.ac".)

A repair for that as part of adding `--disable-prefix` would be very
welcome.

I will look into that.

--

https://rrt.sc3d.org

[Reuben Thomas]

I've looked into it and I can't work out what start/*.ac are used. Having read the various README.txt files and grepped around, I tried removing them (start/configure.ac and start/install2.ac) and it didn't seem to prevent a complete build from git checkout.

However, I see that some generated files like various "configure"s are checked in, so maybe I'm overlooking something, a buried generated reference to those files? (But I can't find install2 mentioned anywhere!)

--

https://rrt.sc3d.org

[Matthew Flatt]

At Fri, 15 Nov 2019 21:33:17 +0000, "'Reuben Thomas' via Racket Users" wrote:
> I've looked into it and I can't work out what start/*.ac are used.

Ah, right again. That explains why I didn't update "start/configure.ac"
to use "path.m4". It's because "start/configure.ac" isn't supposed to
exist. I'm pretty sure we should just delete it.

> However, I see that some generated files like various "configure"s are
> checked in, so maybe I'm overlooking something, a buried generated
> reference to those files? (But I can't find install2 mentioned anywhere!)

The checked-in `configure` scripts are generated by "make-configure" in
"racket/src/ac", and that script doesn't refer to "start/configure.ac".

[Reuben Thomas]

On Sat, 16 Nov 2019 at 15:06, Matthew Flatt <mfl...@cs.utah.edu> wrote:

The checked-in `configure` scripts are generated by "make-configure" in
"racket/src/ac", and that script doesn't refer to "start/configure.ac".

Thanks for the confirmation. What about start/install2.ac?

--

https://rrt.sc3d.org

[Matthew Flatt]

Also should be removed. That one was probably an intermediate file from
conversion that I missed in cleanup.

[Reuben Thomas]

Great, I'll add a commit to remove those two files to my eventual PR on this issue.

--

https://rrt.sc3d.org

[Reuben Thomas]

https://github.com/racket/racket/pull/2915

--

https://rrt.sc3d.org