forked from chapel-lang/chapel
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Install Python-based tools using
make install
; make changes to `chp…
…l` and `chpldoc` to work better in prefix installs (chapel-lang#24492) This PR was created with the intention of adding support for installing `c2chapel` and other Python-based tooling when it has been built. However, doing so -- particularly in the prefix-based installation case -- required some additional implementation work in `chpl` and `chpldoc`. The main problem was the `CHPL_THIRD_PARTY` directory, which is transitively (via `chpl_home_utils.py`) used by all the `run-in-venv` scripts and `chpldoc`. Two problems stemmed from the environment variable: * This directory is correctly inferred when the environment is completely blank, but in an explicitly-set `CHPL_HOME`, it points to an (assumed) home-based directory. Thus, `export CHPL_HOME=$(chpl --print-chpl-home)` breaks both `chpl` and `chpldoc`. * It's very hard to find this directory (and therefore `chpldeps`, which goes through `CHPL_THIRD_PARTY`) when the top-level program is a bash script invoked from `/bin`. In particular, invoking `chpl_home_utils.py` etc. requires knowing the path to `/share`, which the first running script doesn't know. So we need some sort of bootstrapping. This PR addresses this by adding a `--print-bootstrap-commands` developer flag to Chapel, which prints a couple of `export` statements with `CHPL_HOME` and `CHPL_THIRD_PARTY`. These statements are enough to locate and get proper output from `chpl_homeutils.py`, which I expect to be the source of truth for subsequent queries. It also fixes the "incorrect `--prefix` detection" issue by adjusting the `CHPL_HOME` processing logic. While adjusting the `CHPL_HOME` logic, I noticed that it lives in two places: Dyno and the production compiler. I believe that the Dyno version is a port of the production version; I did my best to simplify the Dyno version, and then called out to it from the production compiler. The net result should be that `chpldoc` and `chpl` behave the same way w.r.t. environment variables. Since in Dyno we use C++ strings etc., the logic (which until now used `fprintf` and fixed-sized buffers, and returned on length errors) has been considerably simplified. Only the production compiler is left to use fixed-size buffers, and one corresponding length check is left to support that. Reviewed by @arezaii -- thanks! ## Testing - [x] paratest - [x] `test_install`
- Loading branch information
Showing
9 changed files
with
176 additions
and
204 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.