fix 2698: cImportPaths doesn't work with dmd and ldc #2818
Conversation
|
✅ PR OK, no changes in deprecations or warnings Total deprecations: 8 Total warnings: 0 Build statistics: statistics (-before, +after)
executable size=5293368 bin/dub
-rough build time=62s
+rough build time=61sFull build output |
Everything is in place for it to work, so it could do it. |
|
Tested (on my machine) with ldc2 1.35.0 based on DMD v2.105.2 Moving on to adding a test case to $REPO/test. Will the automatic test runner be running with a new enough version of ldc? |
|
Looks like the test is failing ? |
The test script attempts a build of a dummy project first with dmd, then with ldc via dub's --compiler flag. The jobs labeled with dmd fail at the ldc step, and the jobs labeled with ldc fail at the dmd step. Do the jobs labeled with a certain compiler not have any of the other compilers installed? |
That's correct, to prevent those kinds of mistake. |
So if I change test/issue2698-cimport-paths-broken-with-dmd-ldc.sh to simply call ${DUB} build --root test/issue2698-cimoort-paths-broken-with-dmd-ldc, is this redundant? I noticed there's a test/run-unittest.sh that will go through and run dub build/run/test on every folder in test/ that doesn't have a special dotfile to disable build/run/test. Should I delete the issue-specific .sh file (which only call dub build) and depend on run-unittest.sh |
|
Yes, if you have have something that just succeeds/fails with |
|
Ok, so the only builds that are failing at the moment are windows builds with dmd. Here is the relevant output: I hate to point fingers......but it looks to me like this error is unrelated to my changes. It'll take me a little time to get a dev environment set up on windows to look into this. In the meantime, do you (@Geod24) see anything obvious to point me in the right direction? |
|
@apbryan In order for ImportC to work, Visual Studio(or Build Tools) and Windows SDK must be installed and the Visual Studio environment variables must be set. Unlike LDC, the environment variable setting process in dmd does not seem to be working properly yet. |
|
@apbryan : I took the liberty to rebase your PR and try a solution to the problem. That didn't quite work, I'll try a few more things tonight. |
Wonderful. I haven't had time to dig into this myself (doing very important work playing stormgate). It's nice to see the work being done! |
|
@Geod24 - name: '[Windows] Add VC toolset to PATH (DMD only)'
if: ${{ runner.os == 'Windows' && env.DC == 'dmd' }}
uses: ilammy/msvc-dev-cmd@v1 |
|
@apbryan @Geod24 |
| int bar(void) | ||
| { | ||
| printf("func bar in foo.h\n"); | ||
| } |
There was a problem hiding this comment.
Writing the implementation in .h files is a terrible practice.
How about declaring the type as a struct or something instead of a function?
|
I think this PR would pass the test now. |
|
Looks like one automated test failed (buildkite/dub) because whatever box/VM it was running on didn't have a new enough version of LLVM to build ldc with. From the log: |
Addresses issue 2698 where the wrong flags are passed to dmd and ldc2 such that cImportPaths do not work. I tested with the dmd version I have currently installed (2.106.1), but have not tested with the old version of ldc2 I have (1.28.0 based on dmd 2.098.0) as it does not appear to support the -P arg for passing C preprocessor flags
Still need to:
Open question: should dub attempt to detect if the version of the compiler supports cImportPaths ?