In my project there is a call to symstore.exe in build script. Sure
you can add a target, but its not necessary imho.
2011/5/22 Paul Harris :
> Hi,
> http://www.stackhash.com/blog/post/Setting-up-a-Symbol-Server.aspx
> I read this blog and thought it would be great to have cmake generate a
> "SYMS
> CMake uses prefix+base+".pdb" to generate the PDB file name, however I
> didn't dig deep enough to find out what `base' is, just that it is
> obtained with cmTarget::GetName(). Whether that refers to the target
> name or the OUTPUT_NAME, I couldn't find out easily, so you'll have to
> experiment
> We have a clang.exe and a clang.dll. While building, VS creates
> clang.pdb (for the executable) and clang.pdb (for the dll) which
> obviously is not right. Is there a way to tell VS to use a different
> name for the PDB?
You can use different project name for exe and set the output name via
OUT
I've already posted the question about different targets with the same
name. I'm trying to change my project's cmake configuration towards it
like this (this is a very simplicated example):
|-- foo
| cmake_foo1
|--- CMakeLists.txt
| cmake_foo2
|--- CMakeLists.txt
|
| bar.cpp
|-
> Usually there are 2 ways: 1) put them into separate directories (like Debug
> and Release), probably specifying different output directories or 2) use
> different file names, say adding suffixes like D, or d8.
> BTW, what's the point to have different configurations in the same workspace
> (do y
> I am not a Visual Studio user so I may be missing your point here
> but why having foo_1 and foo_2 ending up in the same workspace is a problem?
>
> As long as the lib/dll end up in separate dirs (using *_OUTPUT_DIRECTORY).
Workspaces become too large, so I would like make'em smaller.
> Should
> You can definition two different library target
> and use OUTPUT_NAME property to adjust the name
>
> add_library(foo1 ${foo_source})
> set_target_properties(foo1 PROPERTIES
> OUTPUT_NAME foo)
>
> add_library(foo2 ${foo_source})
> set_target_properties(foo2 P
Hello CMakers,
suppose I've got a library foo with tow configurations: foo_1 and
foo_2. Both versions should have the same output name: foo. The
problem is, the output directory for both ist the same, so the second
will overwrite the first.
What's the best way to organize it?
--
BG,
Alexey
__
You can install target and data and then run your program.
2011/1/26, Benjamin Kurz :
> Hello everyone,
>
> Currently I'm using cmake for building my c++/Qt project.
> The source directory structure looks like this:
> Project
> |_ src
> |_ include
> |_ data
>
>
> Currently I run cmake from the sou
It looks that precompiled headers should help here.
2011/1/17 David Cole :
> See this command:
> http://cmake.org/cmake/help/cmake-2-8-docs.html#command:include_regular_expression
>
> If you can match many of the "header files that rarely, if ever, change"
> with a regular expression based on dire
> Thing is, you can't *rely* on DESTDIR *not* being used by the user of
> your project. If a user shoots himself in the foot, that's his fault,
> but when designing your test architecture you IMHO shouldn't make the
> use of DESTDIR impossible. I'm sure Debian/Ubuntu/the/whole/zoo would
> object to
> Why can't you just set CMAKE_INSTALL_PREFIX to some path that you know and
> then reference that from your tests that run the installed version?
I thought about it, but I'd like to keep it independent of some known
path. If you mean, there is no other way, I should give them a try.
> DESTDIR wi
> Which software licence does belong to your approach?
I don't know :)
--
BG,
Alexey
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check
> Well, if you don't want any help fixing the real problem, then the
> answer is simple: CMake can't possibly give you that information because
> of DESTDIR.
Thank you.
> So, go and fix your project.
I wish I could, but its not so simple. If you have an idea, just let me know.
--
BG,
Alexey
__
Here is the code:
find_file(myproject_BUILD_NUMBER_FILE_FOUND myproject_build_number.txt
PATHS ${myproject_SOURCE_DIR})
if(${myproject_BUILD_NUMBER_FILE_FOUND} MATCHES "NOTFOUND")
set(myproject_CURRENT_BUILD_NUM 1)
else()
file(READ ${myproject_SOURCE_DIR}/myproject_build_number.tx
As I mentioned above, there are targets foo1 and foo2, build from foo
sources, and the output name has to be foo. This is the conflict. The
test depends from foo1 and bar2.
> If you don't explain the problem more clearly, people won't be able to
> help you; particularly because I suspect that you
> If the two "version" are needed you may build them in a single build.
>...
> but may be I'm missing something about your "2 versions"?
That's what I already do. The problem is, libv1 and libv2 should be
called libv.
> Alternatively, may be you can decide that your needed
> "temporary" install wi
> Yes, make the tests run without installation. To give more advice, we'd
> need to know more about those "dependencies". Are they other
> executables? Data files? Libraries?
Well, if I could do that, I wouldn't ask ;)
I have 2 versions, which are built from the same sources. So I have to
have 2 d
2011/1/12 SF Markus Elfring :
> Hello,
>
> I would like the add the CMake approach for software generation to a
> project. My project example supports also other build tools.
> This has got consequences on the way how informations like version numbers
> are shared between these approaches.
>
> The
> What do you want to do?
I have some tests, which cannot be run without installation because of
dependencies. So I need to specify the install path to add_test. Is
there a better approach?
--
BG,
Alexey
___
Powered by www.kitware.com
Visit other Kitw
Hello,
how can I determine the path to installed target? The problem is, if I
set DESTDIR for example "D:\", I the install path becomes
"D:\Programme\", so I cannot use DESTDIR to determine
the path.
--
BG,
Alexey
___
Powered by www.kitware.com
Visit o
21 matches
Mail list logo
