On Thu, 2019-04-04 at 06:56 +0100, Stephan Menzel wrote:
> add_library(mylib STATIC mysources)
> add_excecutable(mytest mytest.cpp)
> target_link_libraries(mytest mylib)
>
> Now although I don't understand the exact reasons behind that, over
> the years came to accept that depedencies between the
Could you share more details about your CMake version, the platform you're on,
and the generator you're using?
I haven't run into this issue (and it's pretty counter to how I'd expect CMake
to behave). The only similar setting I'm aware of is
https://cmake.org/cmake/help/latest/prop_tgt/LINK_DE
Hello again,
no ideas so far? Perhaps I can elaborate. I have tried multiple approaches
over the years. Most recently adding the source files of the lib explicitly
as dependencies to the created executable.
Like this:
set (SRC
MySource1.cpp
MySource2.cpp
)
set (HDR
MySource1.hpp
MySource2.hpp
)
To follow up on this, I tried creating a .bat file to run my program with the
required command line arguments, but I was unable to add a shortcut to the .bat
file because cmake appends ".exe" to the name of the executable in
CPACK_PACKAGE_EXECUTABLES.
I think the only way to make it work is to
On Wed, Apr 3, 2019 at 2:50 PM Martin Weber
wrote:
> To implement the 'index only files referenced through the build script'
> view,
> *any* IDE would have to *interpret* the build scripts.
> Just choose an IDE that has a build script interpreter to solve your use
> case.
>
Qt Creator and Visual
Oops, meant to send this to the mailing list, but GMail keeps trying to
divert me.
-- Forwarded message -
From: Benjamin Shadwick
Date: Wed, Apr 3, 2019 at 2:52 PM
Subject: Re: [CMake] Eclipse generator question
To: Martin Weber
On Wed, Apr 3, 2019 at 2:18 PM Martin Weber
wrot
Am Mittwoch, 3. April 2019, 22:55:45 CEST schrieb Benjamin Shadwick:
> FYI,
>
> I opened a bug on CMake's tracker about updating the CMake generator since
> its outputs are kind of garbage for modern CDT releases:
> https://gitlab.kitware.com/cmake/cmake/issues/19107
>
> Unfortunately the only fe
Am Mittwoch, 3. April 2019, 22:26:59 CEST schrieb Benjamin Shadwick:
> I tried cmake4eclipse, and it's a mixed bag. It requires a lot of tweaking
Really? Just set _CMake Builder (portable)_ as the current builder and build.
> of the Eclipse project after you create it, and I'm pretty sure it suff
FYI,
I opened a bug on CMake's tracker about updating the CMake generator since
its outputs are kind of garbage for modern CDT releases:
https://gitlab.kitware.com/cmake/cmake/issues/19107
Unfortunately the only feedback I got was that there is a push to remove
*all* generators in favor of forcin
Am Mittwoch, 3. April 2019, 18:44:04 CEST schrieb Benjamin Shadwick:
> Update - I think I found a tolerable workaround:
>
> If I invoke cmake with -DCMAKE_ECLIPSE_GENERATE_LINKED_RESOURCES=OFF and
> then inject a link to my include directory into the .project file, things
> work a lot better:
You
I tried cmake4eclipse, and it's a mixed bag. It requires a lot of tweaking
of the Eclipse project after you create it, and I'm pretty sure it suffers
from the same problem of leaving you with an Eclipse project whose source
tree reflects what is in the filesystem rather than what is defined in the
Hi there,
Apologies in advance if this is not the correct mailing list.
I'm working on a C++ project which has existing CMake files and works on
Linux and Mac. I was attempting to build it on the Android NDK
cross-compiling to ARM64, and ran into an issue.
In particular, the toolchain determinat
Am Mittwoch, 3. April 2019, 18:44:04 CEST schrieb Benjamin Shadwick:
> Update - I think I found a tolerable workaround:
>
> If I invoke cmake with -DCMAKE_ECLIPSE_GENERATE_LINKED_RESOURCES=OFF and
> then inject a link to my include directory into the .project file, things
> work a lot better:
> -
Update - I think I found a tolerable workaround:
If I invoke cmake with -DCMAKE_ECLIPSE_GENERATE_LINKED_RESOURCES=OFF and
then inject a link to my include directory into the .project file, things
work a lot better:
- I get only one copy of each source file in the Open Resource dialog.
- I get sour
Awesome, thanks!
On Wed, Apr 3, 2019 at 10:26 AM Brad King wrote:
> On 4/3/19 10:09 AM, Zaak Beekman wrote:
> > They contain the mod files. I didn't ask for a $ directory to
> > be created for me within the CMAKE_Fortran_MODULE_DIRECTORY but it's
> > there, and all the .mod files are inside it, s
On 4/3/19 10:09 AM, Zaak Beekman wrote:
> They contain the mod files. I didn't ask for a $ directory to
> be created for me within the CMAKE_Fortran_MODULE_DIRECTORY but it's
> there, and all the .mod files are inside it, so `install(DIRECTORY
> ...)` is incapable (at least in my testing) of fetchi
Thanks so much Brad!
On Wed, Apr 3, 2019 at 9:35 AM Brad King wrote:
> The `install(DIRECTORY)` approach is the current recommendation.
OK
> Do those directories contain the `.mod` files or are they extra?
> In the latter case, use `install(DIRECTORY)`'s options for excluding
> content by patt
On 3/31/19 5:10 PM, Zaak Beekman wrote:
> What's the best approach for handling cross-platform (i.e., MSVS, Mac,
> Linux) installation of Fortran module files associated with
> libraries?
The `install(DIRECTORY)` approach is the current recommendation.
> problems and drawbacks remain:
>
> 1. Wi
Hi all,
This didn't get any bites, so I'm re-sending it. Any thoughts, however
short they may be would be appreciated. Right now, the only obvious
solution to me is to use `install(SCRIPT ...)` where a script uses
`file(GLOB_RECURSE ...)` to enumerate modules and submodules in the
build path, foll
19 matches
Mail list logo
