On Tue, Aug 22, 2017 at 12:42 PM, Clément Gregoire wrote:
> No you're not meant to specify paths yourself, you should just use
> find_library.
> Check how modules such as FindTIFF.cmake are implemented.
>
Please doc in CMake all the things I am "meant to" so as I can live inside
that happy littl
Hello
I'm busy today.
So I'll try tomorrow or the day after tomorrow.
Regards
Masaru.
2017年8月23日(水) 0:36 Brad King :
> On 08/21/2017 05:56 PM, masaru tsuchiyama wrote:
> >> https://gitlab.kitware.com/cmake/cmake/issues/17191
> > I think it is same as the issue.
> > I use Japanese version of Wi
No you're not meant to specify paths yourself, you should just use
find_library.
Check how modules such as FindTIFF.cmake are implemented.
Le mar. 22 août 2017 à 19:05, Brian Davis a écrit :
>
> and provide future
>
> target_link_directories(
>targ
>INTERFACE
>debug ${TOP}/build/x64
Another reason to reduce the number of binary directories is that
there are different ways of managing third party libraries. One in
particular that we use is to clone a repository into the binary
directory and build all third party libs in real time based on a
toolchain file (Similar to the functi
I think the documentation also fails to mention that link dependencies
propagate even when "PRIVATE" is used, if the target is a static library.
On 22 Aug 2017 4:40 pm, "Brad King" wrote:
> On 08/22/2017 11:36 AM, Robert Maynard wrote:
> > The `Transitive Usage Requirements` section of the c
and provide future
target_link_directories(
targ
INTERFACE
debug ${TOP}/build/x64/Debug/Libraries/
optimized ${TOP}/build/x64/Release/Libraries/
)
with debug / optimized / general capability
then targets could support multiple debug / release dirs even if CMake
(CMAKE_INSTALL_PREFIX
Upon further reflection the abs paths for every lib is absolutely not
defensible.
1) Pass only the short lib name to target_link_libraries
2) Add absolute path to future target_link_directories if you must
Then it's one (1) long path on the command line string and not N long paths
fore each lib
On 08/22/2017 11:36 AM, Robert Maynard wrote:
> The `Transitive Usage Requirements` section of the cmake-buildsystem
> documentation quickly covers this idea but it could be elaborated on.
> This might be a good place for a concrete example.
Yes. Showing the transitive header case as an example w
The `Transitive Usage Requirements` section of the cmake-buildsystem
documentation quickly covers this idea but it could be elaborated on.
This might be a good place for a concrete example.
Any thoughts Brad?
On Tue, Aug 22, 2017 at 11:31 AM, Miller Henry
wrote:
> Is that the right place to say
On 08/21/2017 05:56 PM, masaru tsuchiyama wrote:
>> https://gitlab.kitware.com/cmake/cmake/issues/17191
> I think it is same as the issue.
> I use Japanese version of Win10 Pro.
Thanks. Unfortunately I've not been able to reproduce it.
See discussion in the issue.
Since you have a local build yo
Is that the right place to say things like
If a header file contains
#include
Then OtherLibrary is probably candidate for PUBLIC, if the header contains the
predeclaration
class OtherLibraryClass;
then OtherLibrary should be PRIVATE?
I'm not against putting that content in of
C comments
On Tue, Aug 22, 2017 at 8:01 AM, Robert Maynard
wrote:
> Usage of link_directories is discouraged, and was part of the reason
> why a target based option was not added. As the documentation for
> link_directories states "Note that this command is rarely necessary.
> Library locations
On Tue, Aug 22, 2017 at 10:45 AM, Robert Maynard wrote:
> You could look at extending the official CMake documentation,
> specifically the build system documentation (
> https://cmake.org/cmake/help/v3.9/manual/cmake-buildsystem.7.html ).
>
> The documentation is all in restructure text and we ac
You could look at extending the official CMake documentation,
specifically the build system documentation (
https://cmake.org/cmake/help/v3.9/manual/cmake-buildsystem.7.html ).
The documentation is all in restructure text and we accept
documentation changes through our gitlab instance.
cmake gitl
I've been playing with the private/public/interface keyword to
target_link_libraries. It seems to me that WHAT they do is well documented, but
nobody has ever actually documented what they correct rules of WHEN/WHY you
should use any of them. After a lot of misstarts I think I've started to
un
Sorry I forgot to answer your last set of questions:
CommonLib is indeed 2 things:
* A common (static or shared) library for native code (most of our
CMake targets specify CommonLib as a link dependency)
* A common library for Java code (we do specify this as a dependency
for most java targets in
Thanks to both of you for responding.
First, to Jom's reply: The "x" part is what I was worried about. Each
"path" resulting in a single binary dir. This is the part that I think
could be optimized. I'll explain more on this later. Note also that
this optimization might only benefit my specific st
Usage of link_directories is discouraged, and was part of the reason
why a target based option was not added. As the documentation for
link_directories states "Note that this command is rarely necessary.
Library locations returned by find_package() and find_library() are
absolute paths. Pass these
18 matches
Mail list logo
