Skip to content

Conversation

@filmil
Copy link
Contributor

@filmil filmil commented Jan 13, 2026

Would you be open to a change like this one?


The following can be set using environment variables:

  • NVC_LIBEXEC_DIR
  • NVC_LIB_DIR
  • NVC_DATA_DIR

Useful for running NVC in sandboxed environments where the dir locations are not predictable.

The following can be set using environment variables:

- NVC_LIBEXEC_DIR
- NVC_LIB_DIR
- NVC_DATA_DIR

Useful for running NVC in sandboxed environments where the dir locations
are not predictable.
@nickg
Copy link
Owner

nickg commented Jan 13, 2026

Do you really want the directories to be completely arbitrary locations specified at runtime, or do you just need to be able to move the whole install directory around, so that the directories are relative to the executable's location like the Windows build?

I don't really like environment variables that change behaviour like this as it's easy to end up with a broken system that's very difficult to debug by accidentally setting one and then forgetting about it.

@filmil
Copy link
Contributor Author

filmil commented Jan 14, 2026

Do you really want the directories to be completely arbitrary locations specified at runtime

In a way yes.

Mostly, no absolute paths which exist during NVC compilation are usable when NVC is used as a build tool in a sandboxed environment. I build the nvc binary in a sandbox, so any absolute compile-time paths (libexec, for example) would refer to ephemeral directories, which would no longer exist when nvc is then used as a build tool. It is then also used in a different sandbox, which again has a different ephemeral path.

I think the behavior I'm after would be similar to how you specify -system and -isystem flags to LLVM so it knows where to find the compiler's required files. With these flags set properly, it does not matter where the compiler was built/installed.

I don't really like environment variables that change behaviour like this

I figured it might be contentious, hence the question.

@nickg
Copy link
Owner

nickg commented Jan 17, 2026

So how about if we add a configure flag --enable-relocatable which defaults to true on Windows and false on other platforms. If false we embed the value of --prefix (or --libexecdir, etc. if specified) in the executable, if true we calculate the value of --prefix at runtime relative to the executable location (e.g. $(dirname $(/proc/self/exe))/../libexec, like the #ifdef __MINGW32__ block does today).

../configure --prefix=/some/temp/dir --enable-relocatable
make && make install
mv /some/temp/dir /some/other/location

Will that work for you?

@filmil
Copy link
Contributor Author

filmil commented Jan 17, 2026

Will that work for you?

Thank you for the suggestion. As you may remember, I'm interested in sandboxed builds, and there you typically cannot compute the path of one sandbox item by knowing the path of another.

While I could rig it, this approach doesn't help directly, and I don't want to have everyone else pay the complexity tax for this new flag. :)

Between that, and maintaining a small patch on the side, I'm happy with the latter. Also, less work for you.

Thanks for considering it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants