-
-
Notifications
You must be signed in to change notification settings - Fork 267
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
ldc2.conf: Implement ~=
concatenating operator
#4848
base: master
Are you sure you want to change the base?
Conversation
b85e1aa
to
2a2aafa
Compare
It seems that my change to have the multilib filler script depend on ldmd2 instead of ldc2 isn't really correct. On a system without ldc2 installed the build is expected to fail since ldmd2 will probably be built before all the object files of ldc2 and then, when run, it would fail to find a ldc2 executable which will make the whole build fail. The change was meant to solve the circular dependency issue between every object file that needed to be compiled by the built ldc2 requiring the config file to be configured and the config file requiring ldc2. The old behavior of having everything add a dependency both on ldc2 and the config file I think is the worst approach since it pushes the issue downstream on the whole cmake file instead of solving it at the root. Other solutions I thought of are:
I'm not sure which one is best. I think I prefer the latter since it feels less hacky but, given that the problem we're trying to solve isn't pretty, the solution that affects the code base the least may be a better choice, even if uglier. |
The failure is definitely from here but the logs are not that useful... |
First of all, thx for the work. In order to make this (more easily) reviewable, please split this up, starting with the 1st commit ( |
a5ab6a0
to
41e66bc
Compare
~=
concatenating operator
Then wrt. the config itself, and making it more easily extensible - my main focus in that regard is simplifying/automating https://wiki.dlang.org/Cross-compiling_with_LDC#Tweaking_the_LDC_configuration_file. I've been promised a little tool ( Then every user could make use of that tool, to simplify setting up cross-compilation, based on the prebuilt binaries on GitHub. I'd like to avoid tampering with the config in CMake as much as possible, because it's such a pain, and patching/extending it after a build much simpler. We most likely don't need the 3 *.conf.in files and could reduce them to a single one. And the whole multilib complication is only a thing for keeping up integrated 32-bit x86 support on Linux (and possibly BSDs). Not sure how much longer that's going to be needed, as the 32-bit libs could be created via |
I could at least help with making the package and making the config section (so no cross C toolchain things at first) and I'll start with implementing it on linux first but I could try extending it once I have something working. Being able to do something like
In regards to multilib, that's exactly what I ended up doing in Gentoo, with only slight adjustments so it's definitely doable. In regards to cmake, making config file generation & configuration more easier was the second goal of my changes. But that's for another PR so we could discuss it there, after I figure out what was failing in CI. |
if (b.isAppending) | ||
newVals = [] ~ a.vals ~ b.vals; | ||
else | ||
newVals = [] ~ b.vals; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The [] ~
prefix isn't really needed, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You need someway to go from const(string)[]
to string[]
. .dup
or newVals ~= a.vals
also works.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've tried to simplified this, and investigate the macOS x86_64 issue a bit in #4856.
|
||
// RUN: %ldc -o- -conf=%S/inputs/invalid_append.conf %s 2>&1 | FileCheck %s --check-prefix=APP |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So this added command curiously fails for macOS x86_64. I'm wondering if that has anything to do with 2 default
sections in the same .conf. Edit: No, seems extremely unlikely after a closer look. Looks more like a segfault during unwinding... we've had similar macOS fun in the past, 'caused' by LTO and/or PGO, and/or different LLVM versions for host clang (Xcode) and LDC (as host compiler for itself).
Similarly to the D counterpart, ~= is used for concatenating arrays. The new behavior of the config file can be summarized by: - go through each section (in the order that they appear in the file) - if the section matches the target triple go through each setting (in the order that they appear in the section) and carry out the assignments. `=` or `:` override the previous value, `~=` appends to it (in the case of arrays). This change can break some setups, mainly setups in which a section contained the same key multiple times. For example: ``` default: { switches = [ "A" ] switches = [ "B" ] } ``` Previously, the above config would pick the flag `A` but this has been changed to picking the flag `B`. Given that the above is unintuitive and users should have easily realized that some of their settings were being ignored, this can be a justified change. Signed-off-by: Andrei Horodniceanu <a.horodniceanu@proton.me> Signed-off-by: Andrei Horodniceanu <a.horodniceanu@proton.me>
41e66bc
to
6a248a8
Compare
I hope you don't intend to keep changing ldc.conf too much. I then need to identify if the user is using that linker or not to add those flags |
The only other change that I'm pretty sure will happen is the possibility of ldc2.conf becoming a directory (so, on a user system it can be either a file like it is now or it can be a directory). If it's a directory you just go through each file, ordered by name, and reapply the parse algorithm over it. But, like I think it has been suggested in the discord channel, isn't it easier to do
Trying to go through ldc2.conf with regexes will just lead to bugs and is way overkill for determining the linker ldc2 is using. |
I would also be grateful for keeping in check the wiki Since it helped a lot in identifying possibilities on where it exists |
Using the config for determining the linker used by the invoked C compiler is... adventurous, and totally unreliable. I also doubt that you really need |
Neither reggae nor dub can build my engine using GNU ld.
These symbols aren't solved because of how the dependencies are being specified. initializer needs core, gl also needs core, but since That behavior only happens on GNU ld and requires either specifying |
Oh wow, so your project has circular link-time deps. Can't you simply emit the
|
That's really strange, because that necessity of identifying the linker was to solve that issue when lld was linking. Mostly when using Neither LLD or MSVC requires those start-end group since they already solve that circular linker issue without any additional requirements. The same isn't true for gnu ld. |
Yeah, |
If these:
are too slow for you use case, sure go ahead and try to implement the parsing yourself but you will eventually run into problems if you only implement a subset of the grammar or you don't check all the possible ways someone can specify the linker. If you still want to go ahead checkout In your implementation I also spotted some bugs:
|
Unless ldc2 has been built with |
No, for wasm in general, as without built-in LLD, the compiler defaults to an external |
You just made me recall that shell execution on linux is way faster than on Windows [I get like 30ms, and my PC is REALLY FAST] , enough to make that time irrelevant. All those timings are way slower on Windows but of course I don't need them on Windows. I might use that -L--version thing on linux. Also, thanks for the points in my implementation, I didn't knew default were always applied
So you're saying that I should only avoid start-end group when building for wasm instead? |
Exactly. And well, not for Windows obviously, and possibly Apple targets (no idea about Apple's |
Thanks, I'll comment out the ldc conf parser, only avoid those flags for wasm and if that issue arises again, I may consider doing the shell exec approach for linux |
Actually, just got that same issue, but on macOS too:
So, yeah, I still need to check the default linker since the default ld on mac may cause issues too |
Couldn't you do an OS check and don't pass the flag on windows or mac but pass it on linux or other unixes, like Martin said? |
I do a cached check of default linker in the beginning of the program. I'll check for ld64 only to be on the safe side for now |
The main goal that I'm trying to achieve with these changes is getting better support for building the compiler and the runtime separately (since that's what I rely upon). Fully doing this, however, is somewhat complicated so I'm trying to do it bit by bit.
In this PR I've implemented:
~=
operator in ldc2.confThe reasoning for this is that both the compiler and the runtime have some sort of switches that they want to encode so, if they are built separately, they can only install (at least) 2 separate files. The
~=
operator is mostly a convenience but it is sometimes useful to be able to append a flag without having to copy all of the default ones.This also has the nice benefit of making the cmake code a little more cleaner since there's no longer a need to go through the whole compiler configuration and then the runtime configuration while keeping track of all the variables that appear in the various ldc2*.conf.in files.
One behavior change that I did do is with:
The older code picked
-A
but now it picks-B
. I think this is justified.I'm curious what you think about this, both the final goal and these specific changes.