[DDMD] Switch to D source and delete C++ source#4923
[DDMD] Switch to D source and delete C++ source#4923MartinNowak merged 1 commit intodlang:masterfrom
Conversation
Yes we do, it's important for this to work that people can rebase onto both sides, the C code and the D code. Everything else means you'll have to manually merge your changes. |
|
Don't close this, I'm using it for autotesting. |
Sorry, I just don't want that anyone merges this. |
I understand. So in your opinion, is it enough to merge #4922 then this? |
Yes should work though I just updated my more complete makefile change. |
Those can be done after the switch. |
|
Auto-merge toggled on |
Woo-hoo! |
[DDMD] Switch to D source and delete C++ source
Yes, thanks again @yebblies for making this happen. Please let's not rush into major rewrites right away. We still have to port some possible 2.068.1 fixes and don't want to loose all PRs. I'd say our main focus for 2.069.0 should lie on making ddmd really fast and ship it with less bugs than the last release. There is no changelog entry btw ;-). |
|
I did rush into making an announcement. I've been so wanting to do that! |
|
This broke the doc autotester. Why was this merged despite the autotester failing? |
Because the doc autotester has been somewhat flaky recently, so I guess everybody just started to ignore it. |
You mean the person who clicked the merge button? ;) The build logs are viewable to anyone, and the failure reason is easy to find. Should we revert this, then? |
No.
It looks like it's not finding the C++ lib, does the test suite pass on that machine? |
|
That machine does not run the DMD test suite. |
|
I figured, I'm asking can it? It looks like some host configuration issue. It should be able to use dmd to link C++ and D together if CC is set to g++. |
|
Yes, it doesn't link against |
|
LDFLAGS is not referenced anywhere in posix.mak now, maybe that's the reason? |
|
This fixes it: diff --git a/src/posix.mak b/src/posix.mak
index aac3017..a0d27c7 100644
--- a/src/posix.mak
+++ b/src/posix.mak
@@ -293,10 +293,10 @@ backend.a: $(BACK_OBJS)
ifdef ENABLE_LTO
dmd: $(DMD_SRCS) $(ROOT_SRCS) newdelete.o $(GLUE_OBJS) $(BACK_OBJS) verstr.h
- CC=$(HOST_CC) $(HOST_DMD_RUN) -of$@ $(MODEL_FLAG) -vtls -J. -d $(DFLAGS) $(filter-out verstr.h,$^)
+ CC=$(HOST_CC) $(HOST_DMD_RUN) -of$@ $(MODEL_FLAG) -vtls -J. -d $(DFLAGS) $(filter-out verstr.h,$^) $(addprefix -L,$(LDFLAGS))
else
dmd: $(DMD_SRCS) $(ROOT_SRCS) newdelete.o glue.a backend.a verstr.h
- CC=$(HOST_CC) $(HOST_DMD_RUN) -of$@ $(MODEL_FLAG) -vtls -J. -d $(DFLAGS) $(filter-out verstr.h,$^)
+ CC=$(HOST_CC) $(HOST_DMD_RUN) -of$@ $(MODEL_FLAG) -vtls -J. -d $(DFLAGS) $(filter-out verstr.h,$^) $(addprefix -L,$(LDFLAGS))
endif
clean: |
Mmh, right dmd doesn't link against |
|
dmd already links against |
|
I'll just remove all references to LDFLAGS then?
Where? I don't see anything relevant in |
Oh, you mean |
|
This pull request caused a ~80% reduction of compilation peak heap usage for an empty program on http://digger.k3.1azy.net/trend/ ! Woah, what happened here? Was the "bump the pointer" allocator replaced with the D GC? |
|
It also caused a 17% increase in linker memory usage, why? Are the object files it emits not the same? |
|
This pull request broke some tests on http://digger.k3.1azy.net/trend/ because some code DMD emits is not Valgrind-friendly, issue filed: https://issues.dlang.org/show_bug.cgi?id=14952 |
4 participants
@WalterBright @MartinNowak
Do we need the switch script in the repo beforehand? I'm thinking not.
I think this is ready to go when it passes the autotester.