-
-
Notifications
You must be signed in to change notification settings - Fork 145
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Import behaves differently for the first run than the subsequent runs #483
Comments
On macOS I cannot reproduce this. I tried with both latest HEAD revision from Fri Sep 15 20:42:54 2023 -0700 (8739d02) and also with an older version from Sat Jul 30 13:07:49 2022 -0700 (b037d4b). In both cases, I get the expected behaviour:
and
@typeless Can you provide details of which version you are running, and maybe |
Hi @petemoore The |
Tup was previously calling getenv("FOO=bar") to retrieve envvar FOO inside tup_db_findenv. This worked on macOS, but not on Linux. Updated to call getenv(varname) instead (e.g. getenv("FOO")). Fixes gittup#483
Tup was previously calling getenv("FOO=bar") to retrieve envvar FOO inside tup_db_findenv. This worked on macOS, but not on Linux. Updated to call getenv(varname) instead (e.g. getenv("FOO")). Fixes gittup#483
Tup was previously calling getenv("FOO=bar") to retrieve envvar FOO inside tup_db_findenv. This worked on macOS, but not on Linux. Updated to call getenv(varname) instead (e.g. getenv("FOO")). Fixes gittup#483
Thank you Mura for the report, and thank you Pete for the fix. I did have to adjust the fix slightly because strndup isn't available in MinGW for some reason, so hopefully I didn't mess it up. I also added a test case (t2243) to check for this behavior. |
By 'first run', I mean running Tup when
.tup
has not been created.To reproduce, create a simple Tupfile as follows:
The text was updated successfully, but these errors were encountered: