Hi Robert,
A solution could be to create a custom build type with specific flags by
appending _build type name to CMAKE_CXX_FLAGS. In that way one could
specify different flags for different build types and then set them as
default for the project they wish to build. This could work like this for
Hi Chris,
Given your file structure
The file structure:
.
|-- bin/
|-- include/
| `-- mylib/
|-- lib/
`-- src/
|-- CMakeLists.txt
|-- mylib/
| |-- CMakeLists.txt
| |-- myfunc.cpp
| `-- myfunc.h
`-- prog/
|-- CMakeLists.txt
`-- prog.cpp
you should
Hi Bill,
He wrote
Note also that prog.cpp includes this header via #include myfunc.h.
in his first email, so I thought he wants to include it directly.
Cheers!
Angeliki
On Tue, Dec 2, 2014 at 8:09 PM, Bill Hoffman bill.hoff...@kitware.com
wrote:
On 12/2/2014 1:33 PM, Angeliki Chrysochou
|-- mylib/
| |-- CMakeLists.txt
| |-- myfunc.cpp
| `-- myfunc.h
`-- prog/
|-- CMakeLists.txt
`-- prog.cpp
Cheers!
On Tue, Dec 2, 2014 at 8:09 PM, Bill Hoffman bill.hoff...@kitware.com
wrote:
On 12/2/2014 1:33 PM, Angeliki Chrysochou wrote:
you should add
Glad it worked! No I don't think it is automatically an include path, only
the files in the current directory where your sources are should be by
default an include path.
On Tue, Dec 2, 2014 at 9:05 PM, Chris Johnson cxjohn...@gmail.com wrote:
I'm using Make as my build tool. Here's the
Hi Lars,
What if you provide the working directory to ADD_CUSTOM_COMMAND like this:
add_custom_command(
OUTPUT output
COMMAND command_to_be_executed arg_1 arg_2
DEPENDS ${lib1} ${lib2}
WORKING_DIRECTORY ${EXECUTABLE_OUTPUT_PATH}
VERBATIM)
Would it work?
Otherwise a
Hi Lars,
I see...Why don't you set the working directory then to lib1 and lib2, and
use the full path to App to call App? Not sure it will work, but maybe.
Cheers!
Angeliki
On Wed, Nov 19, 2014 at 7:19 PM, Lars laasu...@hotmail.com wrote:
Hi Angeliki,
Thank you for the suggestions.
I
Hi Rodrigo,
Glad that it is working for you now. I just wanted to mention that I never
had to set the language as properties to the source files since cmake
detects it from the suffix of the source files you list, or at least I
never had a case where the language was not properly detected.
Other
Hi Rodrigo,
Where is the implementation of the undefined references?
If it is in another source file (other than protpred-Gromacs-NSGA2.c, which
seems to be the only one you are compiling) you should add it to the
compilation. If it is in another library that is already compiled, you
should add
Hi Rodrigo,
You have to state to cmake all of your source files for compilation,
otherwise they won't be found in the generated makefiles.
You can do this either by writing all file names individually in
add_executable, or create a variable or a list that contains all of the
file names, or
Hi Glenn,
Adding linker flags exactly in target_link_libraries is not a very good
practice in my opinion. To add specific linker flags to an executable, you
can use the variable CMAKE_EXE_LINKER_FLAGS, which you can edit before
calling add_executable. You could set this variable accordingly in
archive section. I'd be
happy to be proven wrong but I don't think setting CMAKE_EXE_LINKER_FLAGS
will give me that level of control.
--
Glenn
On 21 July 2014 09:57, Angeliki Chrysochou angeliki.chrysoc...@gmail.com
wrote:
Hi Glenn,
Adding linker flags exactly in target_link_libraries
Hi Jörg,
I am not sure if there is a way to do this via cmake, maybe there is and I
don't know it, but I think you need to keep an eye on such things
manually in a way. You could use ldd or readelf to see the exact
dependencies of a library in linux.
All the best,
Angeliki
On Wed, Jul 16,
Hi Mojca,
From what I know cmake will look for libraries in the directories specified
in link_directories(${LIBRARY_DIRS}) and for headers in the directories
specified in include_directories(${INCLUDE_DIRS}) and the property
INCLUDE_DIRECTORIES.
Hi Mojca,
I don't know if removing these paths would break your build maybe...I'm
sorry I couldn't help.
Angeliki
On Fri, Jun 27, 2014 at 11:26 AM, Mojca Miklavec mo...@macports.org wrote:
On Fri, Jun 27, 2014 at 10:42 AM, Angeliki Chrysochou wrote:
Hi Mojca,
From what I know cmake
Hi Michael,
I think what matters is the correctly set dependencies for your build to
succeed (target_link_libraries). By statically link you mean you link
against static libraries that were before shared objects, right? This
should, to my knowledge, not have any influence to how you use
. That means I will need to
update nearly 180 CMake scripts. And, we'll need to make sure any new
scripts contain this value for every instance of TARGET_LINK_LIBRARIES
statement. A painful process!
Thank you for your response, Angeliki.
Mike
On 6/26/2014 1:16 AM, Angeliki Chrysochou wrote:
Hi
Hi Haster,
Maybe CMAKE_CURRENT_BINARY_DIR could help you? Look at its description
here: http://www.cmake.org/Wiki/CMake_Useful_Variables
Cheers!
Angeliki
On Tue, Jun 24, 2014 at 1:51 PM, Haster haster2...@yandex.ru wrote:
Hi folks,
I have such problem:
I build different C/C++ programs
Hi Aurelien,
Even though it is unsafe and not recommended, you could set policy CMP0002
to old so that cmake silently accepts non-unique target names like this:
cmake_policy(SET CMP0002 OLD)
I can't guarantee that your build will then work however.
Another option is to write your own wrapper
19 matches
Mail list logo
