er would
> give a warning on each source file because the build system was passing
> both the default /MD[d] and the additional /MT.
> --
> Daniel Schepler
> --
> *From:* CMake [cmake-boun...@cmake.org] on behalf of Walter Gray [
> chrysal...@gmail.com]
> *Sent:* T
Setting /MT or /MD is pretty important, and is a transitive requirement.
See: https://msdn.microsoft.com/en-us/library/2kzt1wy3(VS.80).aspx
The standard mechanism of using target_compile_options isn't quite
appropriate because it will simply append the flags used by each library
and use the last o
tween building the examples
independently and building them as part of a combined build.
On Thu, Jun 2, 2016 at 10:40 PM Konstantin Podsvirov <
konstan...@podsvirov.pro> wrote:
> Hello.
>
> 8:34, 3 june 2016 г., Walter Gray :
>
> Interesting idea, that could be possible.
>
Interesting idea, that could be possible.
On Thu, Jun 2, 2016 at 8:45 PM Dan Liew wrote:
> > What would be the suggested way to handle this?
>
> Couldn't you build the examples using CMake's ``ExternalProject``
> module [1] and have that build after the main project has finished
> building?
>
>
all
> find_package(). This also is a step toward supporting using the
> library via add_subdirectory(), if that ever becomes a goal.
>
> On Thu, Jun 2, 2016 at 8:06 PM, Walter Gray wrote:
> > I'm currently working on protobuf-3.0.0's cmake scripts, and I've hit a
&g
I'm currently working on protobuf-3.0.0's cmake scripts, and I've hit a bit
of a chicken and egg problem.
There is an examples directory containing a CMakeLists.txt which we would
like to work as both a standalone examples directory and include as a sub
directory of the full build. For obvious rea
I was about to ask the list, but some googling lead me to this:
https://github.com/polysquare/cmake-unit
I am not the developer, but he doesn't appear to be on here so I thought I
should share. This looks incredibly useful
--
Powered by www.kitware.com
Please keep messages on-topic and check t
n't exactly the same version, which is unsupported under
> protobuf IIRC.
>
> Hope that helps,
> Dave
>
> On Tue, May 24, 2016 at 5:02 PM, Walter Gray wrote:
>
>> @Hendrik - Yes, unfortunately it didn't help me too much.
>> Superbuilds are not really an a
It occurs to me that, much like C++ itself, there are wide variety of ways
to do things in CMake, many of which exist only for legacy compatibility,
and the language had a lot of active develpment recently that allows much
safer, easier to read programs. C++ now has the Core Guidelines and lots of
;> bit easier to tell what's going on. The method in the above link would only
>> be better if you really needed to keep everything in the one single build.
>>
>>
>>
>>
>> On Sat, May 21, 2016 at 11:10 PM, David E DeMarle <
>> dave.dema...@k
in terms of concepts, I think I would want a find_package that
understood the difference between finding a package for executing and
finding a package for linking, but that'd be a pretty fundamental change.
On Fri, May 20, 2016 at 7:02 PM Walter Gray wrote:
> I've got a project wit
I've got a project with a number of target platforms, including some that I
have to cross-compile to such as android, that uses protobuf. If you're
unfamiliar, the crux of the issue is that there is both a library,
libprotobuf, and an 'compiler', protoc, that takes .proto files and
generates a .h/.
Hey All -
I'm trying to add a custom command to some targets to copy files using a
usage requirements kind of pattern, but I'm running into some
limitations in CMake that seem somewhat arbitrary. To set the stage,
imagine the following toy example:
DirectoryA's CMakeLists File:
include_direc
Hey all,
I'm working on a module that will allow me to automatically copy all the
required .dll files as defined by well-formed import library targets to
the appropriate location (same folder for windows, Frameworks folder for
OSX bundle, ect). I've got the code that scans an executable's
INT
I was working on a find module, and ran into some rather unpredicted
behavior - it appears that including ENV ProgramFiles at the end the
list of PATHS makes the search fail! Remove that line, put it first, or
put it in quotes, and it works just fine. Does anyone have any clue why
this might
I've been trying to figure out how to correctly author install steps for
a library that will generate a self-contained folder that can be
distributed and used by others, including a good Config.cmake
file and I ran into what seems like a bug. If you say
install(EXPORT DESTINATION .)
Then th
Glen is correct. You should take a look at the docs for interface modules
here:
http://www.cmake.org/cmake/help/v3.0/manual/cmake-buildsystem.7.html#interface-libraries
I also put up some examples of how to do this on github a while back.
https://github.com/wal-rus/cmake-modules
Hope that helps
Hey List -
Just wanted to put this out there for posterity, and in case anyone runs
into the same question I had. I had a bunch of nearly identical
functions, so I wanted to write a function to define them for me to
reduce code repetition. The problem I ran into was that if you write
macro(
Hey all,
You may have seen my earlier posts, "find_package" and INTERFACE targets
in 3.0" and "Target usage requirements for shared libraries". I've also
seen Michael Darling's post "Package found - passing _INCLUDE_DIRS to
include_directories() and _LIBRARIES to target_link_libraries()", so I
dule writers can use,
either on a CMake module or integrated.
So currently, you can either guess or use UNKNOWN.
Regards,
HS
On 19. Juli 2014 05:13:13 MESZ, Walter Gray wrote:
Thanks Nils!
The examples in the git repo are particularly helpful. It seems that
in
all of the examples, the library
Unless I'm mistaken, it says that the *CONVENTION* is to call
include_directories(${_INCLUDE_DIRS}) manually, not that
it is done automatically. To get that kind of automatic include
directory adding you need to have an import or interface target with
INTERFACE_INCLUDE_DIRECTORIES defined by t
ter/prop_tgt/IMPORTED_LOCATION.html
On 7/18/2014 5:23 AM, Nils Gladitz wrote:
On 07/18/2014 05:00 AM, Walter Gray wrote:
Hi list!
I'm a big fan of the new INTERFACE targets & target usage requirements,
but none of the provided Find.cmake files seem to take
advantage of the new parad
Hi there!
I've got a question I can't seem to find a good answer to: What is the
idiomatic way in CMake 3.0 to handle bundling shared libraries? I've
exhausted my google-fu and all of the examples seem to be from before
CMake 3 was released. None of them take any advantage of 3.0's new and
IMO
Hi list!
I'm a big fan of the new INTERFACE targets & target usage requirements,
but none of the provided Find.cmake files seem to take
advantage of the new paradigm. Checking the wiki, the old
Find.cmake seem to be deprecated, with most of the information
on authoring new packages assuming
24 matches
Mail list logo
