- User Since
- Dec 9 2012, 11:41 PM (370 w, 5 d)
Mon, Jan 13
Do we need to worry about compatibility? What happens if there is a mix between an old binary and a new binary?
I'm not sure I understand the motivation for this change. Can you please expand on that? How are you using it that it doesn't work for you? Additionally, z is definitely the wrong name, please compute that by using get_file_name_component, CMAKE_SHARED_LIBRARY_PREFIX, and string(REGEX...)
Tue, Jan 7
Thu, Jan 2
Wed, Jan 1
Hmm, I see, yes, that would change the behavior where we would not create the targets for it. In that case, using EXCLUDE_FROM_ALL is fine, but set it as a target property rather than passing global variables like this. But, even better would be to understand if we even need this.
Tue, Dec 24
Mon, Dec 23
Sun, Dec 22
Dec 16 2019
Dec 12 2019
Dec 10 2019
Should probably add a check for __block variables.
Dec 9 2019
The std::transform better expresses the intent IMO. I think that it is definitely more idiomatic C++, so I think that is an improvement.
Dec 7 2019
Dec 6 2019
Dec 4 2019
LGTM with the additional test for the size/type mismatch validation.
Dec 3 2019
There isn't a workaround for this, its just a bug in our CMake. I've fixed the issue with our CMake logic in GIT 372ad32734ecb455f9fb4d0601229ca2dfc78b66.
Nov 29 2019
The commit message doesn't really explain much. Why simply consume the argument? Why not actually halt the build since this clearly is conflicting, and its unclear what the user intended.
Could you please provide a proper commit message before committing this? Also -Xifs is actually the inverse of what you want - that would be a set of arguments designed to be passed to llvm-ifs.
Nov 27 2019
@labath I think you are misunderstanding the patch. This is not autoselecting the dependencies. It is simply doing that based on an existing option that we have - LLVM_ENABLE_ZLIB. We could always search for zlib and override the results with LLVM_ENABLE_ZLIB as well. The current build will continue to just work - zlib is used only for the compressed debug sections (which requires the user to opt-in).
Nov 26 2019
Nov 23 2019
I think that rather than adding more wrapping macros, we should fix the structure. We can mark the examples directory from ALL at the add_subdirectory level and only add the subdirectory when examples are enabled. This avoids the need for the new macro. I think that we want to move towards a more standard cmake build rather than a more specialized one.
Nov 22 2019
Use @labath's suggestion of bumping minimum required version for Windows
Nov 21 2019
Nov 18 2019
Sorry about the delay on the review!
The test adjustments are incorrect. They should optionally accept the triple in the path.
Nov 17 2019
Nov 16 2019
Nov 12 2019
Nov 11 2019
I'm kinda torn on this. Although this simplifies the build, linking the DSO on Linux is painful unless you externalise the debug info (i.e. build with fission). On the other hand, people should be encouraged to setup the distributions and use that to build the full set that they need. I think that marking libLLVM as EXCLUDE_FROM_ALL is a decent compromise.
Nov 8 2019
Nov 6 2019
I agree with @efriedma that it sounds odd, could you explain that please?
Can you please write a more complete commit message explaining the need for this.
Nov 4 2019
Seems like a good idea since lld link2 has been made into lld link for a while now.
Nov 2 2019
Nov 1 2019
Oct 30 2019
Oct 29 2019
Yeah, doing an incremental rollout makes sense.
Oct 28 2019
The reason for bringing this back up as a Windows specific thing is that currently, there is no good way to build LLDB with python support without having to specify additional details on *just* windows because the windows path is doing something special. This is trying to bring the windows path to parity with the Linux path.