kimgr wrote:
https://github.com/llvm/llvm-project/pull/103388 was merged, I think I know how
to work this now. Thanks everyone for helping!
https://github.com/llvm/llvm-project/pull/97197
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https:/
https://github.com/kimgr closed https://github.com/llvm/llvm-project/pull/97197
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
kimgr wrote:
@tstellar
> I think that the GetResourcesPath function is incorrect. There's no reason it
> should return a wrong value, since the CLANG_RESOURCE_DIR value is always
> known at compile time.
Please see https://github.com/llvm/llvm-project/pull/103388 for an attempt to
make this
kimgr wrote:
> The exported target is new and hasn't been in a release yet. It should be in
> LLVM-19 once it's released and Debian gets updated. Of course, this is also
> true of any other new thing that gets added now anyway.
👍
> I am a little confused about what your goal is with the path
etcwilde wrote:
> We can't really help you with whatever is wrong with Debian's packages unless
> it is a bug caused by our build configurations. The change you're proposing
> in this PR could just as easily be impacted in some distro's packages.
The exported target is new and hasn't been in a
kimgr wrote:
@llvm-beanz Thanks for clarifying! Yeah, I no longer think this PR has anything
to offer. If you think it's future-proof to assume the interface include dir of
clang-resource-headers is one level down from the resource dir, that works to
polish and seed it into a hardwired `-resou
llvm-beanz wrote:
> So I'm thinking even if the `clang-resource-headers` target was available, it
> would not give the path to the resource dir, but rather the path to the
> subdir containing the builtin headers. That might be fine, i.e. I could take
> that path and add it with `-isystem ...`,
kimgr wrote:
@llvm-beanz
> @etcwilde's point above is that the CLANG_RESOURCE_DIR is already available
> in CMake for projects
> that import the Clang package or are built in-tree with Clang.
I don't think so. As far as I can tell:
* `clang-resource-headers` interface header dir would be th
llvm-beanz wrote:
@etcwilde's point above is that the `CLANG_RESOURCE_DIR` is already available
in CMake for projects that import the Clang package or are built in-tree with
Clang. You can get the directory via CMake with:
```cmake
get_target_property(CLANG_IMPORT_HEADERS clang-resource-header
tuliom wrote:
@kimgr Good points. I agree with you.
https://github.com/llvm/llvm-project/pull/97197
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
kimgr wrote:
> Or making CustomResourceDir = CLANG_RESOURCE_DIR by default instead of "".
Binding that default value in Driver.h would leave it to external projects
(using Clang) to resolve `CLANG_RESOURCE_DIR`, which is not available outside
Clang. So it somehow needs to move into the body of
tuliom wrote:
> I wonder if that last one is a bug...?
Agreed.
> If so, it seems it would be better to just fold `CLANG_RESOURCE_DIR` into
> `Driver::GetResourcesPath` and remove the optional argument.
Or making `CustomResourceDir = CLANG_RESOURCE_DIR` by default instead of `""`.
This would a
kimgr wrote:
@tstellar @tuliom It seems to me _almost_ all callers pass `CLANG_RESOURCE_DIR`
for the `CustomResourceDir` optional argument:
https://github.com/search?q=repo%3Allvm%2Fllvm-project%20Driver%3A%3AGetResourcesPath&type=code
the one exception being:
https://github.com/llvm/llvm-proje
kimgr wrote:
@etcwilde
> The path is already available through the exported clang-resource-header
> imported interface target
I think that one has the full path to the compiler-supplied built-in headers,
not the resource dir (which is basically its parent). We could do some path
mangling, bu
etcwilde wrote:
> That forces us back to the original discussion about exporting
> CLANG_RESOURCE_DIR
The path is already available through the exported `clang-resource-header`
imported interface target.
https://github.com/llvm/llvm-project/pull/97197
_
tstellar wrote:
I think that the `GetResourcesPath` function is incorrect. There's no reason
it should return a wrong value, since the CLANG_RESOURCE_DIR value is always
known at compile time.
https://github.com/llvm/llvm-project/pull/97197
___
cfe-
tuliom wrote:
> `clang::Driver` has this method which allows you to specify the starting path
> for the clang installation to use for the resource lookup.
>
> ```c++
> /// Takes the path to a binary that's either in bin/ or lib/ and returns
> /// the path to clang's resource directory.
> static
kimgr wrote:
> The LLVM_EXTERNAL_PROJECT mode solution using $ won't work
> so well,
> as it pins the resource directory to the build tree. So it won't resolve
> correctly after install, I suppose.
Ah, in that mode I guess we could use the default behavior, and not override
the resource dir.
kimgr wrote:
@llvm-beanz Thanks for the pointers!
Here's what I ended up with as a first step:
https://github.com/include-what-you-use/include-what-you-use/commit/b03f60adb2a9fa884d35bea5eb77c9e8a05d80c0
I couldn't get the `get_target_property` spelling you suggested to work (it
doesn't resolv
llvm-beanz wrote:
@kimgr you should be able to have CMake query the path of libclang and go from
there. Something like:
```cmake
get_target_property(SHARED_LIB_DIR libclang RUNTIME_OUTPUT_DIRECTORY)
```
That should give you the binary location of libclang, which should work for
resolving the
kimgr wrote:
@llvm-beanz Thanks! Yes, copying the headers does seem like a hack, in
retrospect. I think I started down that path because I don't know how packaging
works -- I had assumed I might have to bundle the headers with IWYU, but I
guess the right procedure is to build against an instal
etcwilde wrote:
So, Swift actually has/had a similar issue. We embed a copy of clang in Swift,
so we needed to find the corresponding clang resource headers and install them
with our compiler which is why I wrote
https://github.com/llvm/llvm-project/pull/88317 to expose them. It adds the
clan
llvm-beanz wrote:
(cc @compnerd, @gottesmm, & @etcwilde who have played roles in building and
maintaining all the build-tree stuff for Swift).
https://github.com/llvm/llvm-project/pull/97197
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http
llvm-beanz wrote:
> I think at the time we started doing this, Clang's builtin includes lookup
> basically did `$dirname($0)/../lib/llvm-$version/clang/$version/include`. So
> when building `include-what-you-use` in a separate tree, the resulting binary
> didn't have the builtin headers in the
kimgr wrote:
I think at the time we started doing this, Clang's builtin includes lookup
basically did `$dirname($0)/../lib/llvm-$version/clang/$version/include`. So
when building `include-what-you-use` in a separate tree, the resulting binary
didn't have the builtin headers in the right place,
llvm-beanz wrote:
Is there a reason you need to collect those files for your build tree instead
of using them from where Clang built/installed them?
https://github.com/llvm/llvm-project/pull/97197
___
cfe-commits mailing list
cfe-commits@lists.llvm.or
kimgr wrote:
cc @llvm-beanz -- you seem to have done a fair bit with the LLVM CMake system.
https://github.com/llvm/llvm-project/pull/97197
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-comm
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Kim Gräsman (kimgr)
Changes
I recently opened #95747 to see if it would be advisable to expose
`CLANG_RESOURCE_DIR` from `ClangConfig.cmake`.
Here's a patch to do the most naive thing I could think of, hopefully enough to
trigger discuss
https://github.com/kimgr created https://github.com/llvm/llvm-project/pull/97197
I recently opened #95747 to see if it would be advisable to expose
`CLANG_RESOURCE_DIR` from `ClangConfig.cmake`.
Here's a patch to do the most naive thing I could think of, hopefully enough to
trigger discussion.
29 matches
Mail list logo
