On 09/09/2010 06:53 PM, David Aldrich wrote:
> Hi
>
> As mentioned before, I am replacing a manually built gnu makefile (for Linux)
> that builds a library, with CMake.
>
> A required build step is to run an executable called versionInfo that
> processes all the source files of the library and
On 09/09/2010 09:06 PM, edA-qa mort-ora-y wrote:
> My cmake file has the fairly standard QT setup:
>
> find_package(Qt4 COMPONENTS QtCore QtGui QtXml QtNetwork QtSvg QtOpenGL
> QtMain REQUIRED)
> include(${QT_USE_FILE})
>
>
> and then later use ${QT_LIBRARIES}
>
> However, this uses the debug l
On Thu, Sep 9, 2010 at 3:06 PM, edA-qa mort-ora-y wrote:
> My cmake file has the fairly standard QT setup:
>
> find_package(Qt4 COMPONENTS QtCore QtGui QtXml QtNetwork QtSvg QtOpenGL
> QtMain REQUIRED)
> include(${QT_USE_FILE})
>
>
> and then later use ${QT_LIBRARIES}
>
> However, this uses the de
My cmake file has the fairly standard QT setup:
find_package(Qt4 COMPONENTS QtCore QtGui QtXml QtNetwork QtSvg QtOpenGL
QtMain REQUIRED)
include(${QT_USE_FILE})
and then later use ${QT_LIBRARIES}
However, this uses the debug libraries when I do a debug build. I don't
want that. I want to just u
nevermind I've figured out a generic way to do what I need, build once and
link in multiple locations.
MACRO ( SRC_TARGET_REF _TARGET _REFS_EXPR _SRCREFS )
# 1st obtain the srcs
get_target_property ( _LSRCS ${_TARGET} SOURCES )
#loop through srouces and check matches
foreach ( _TARGET_SRC_FILE
Hi
As mentioned before, I am replacing a manually built gnu makefile (for Linux)
that builds a library, with CMake.
A required build step is to run an executable called versionInfo that processes
all the source files of the library and generates a new source file called
SourceFileInfo.cpp. Th
Sorry for my late weigh in on this one, but there are instances where this
would be useful.
E.g. redistro-ing libMyOneLargeLib.a which may be comprised of several other
smaller libs.
Basically I would like to build once, and pass the .o's into MyOneLargeLib.
My only other alternative to add a c
>From within cmake I see a generation of the .o targets in my makefile, is
there any way to get a listing without shelling out to ar?
--
Cheers,
Timothy St. Clair
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.ki
Benjamin,
> Thank you for your quick answer. I had a quick glance - what I don't
> quite understand is how can I integrate this into my custom cmake
> script? I have a ADD_CUSTOM_COMMAND, and in the depends I need this list
> of dependent files (the generated files, not the xsd's themselves).
>
>
Nevermind, got the build output variables and the install variables
mixed - was causing funny behavior.
On Thu, Sep 9, 2010 at 10:45 AM, Clifford Yapp wrote:
> I've got rather an odd problem, and I'm not even sure how to start
> debugging it. I am building a library and exec files with CMake, an
I've got rather an odd problem, and I'm not even sure how to start
debugging it. I am building a library and exec files with CMake, and
the build appears to succeed. But when I run make install, the files
are gone - erased.
I've traced it as far as a FILE(RPATH_CHECK ...) test in the install
scr
For this chunk it only matters if I can decompose for *nix Makefiles.
Cheers,
Tim
On Thu, Sep 9, 2010 at 7:41 AM, David Cole wrote:
> To the best of my knowledge, there is not an easy, cross-platform way to
> decompose.
>
>
>
> On Wed, Sep 8, 2010 at 11:43 PM, Tim St. Clair wrote:
>
>> I guess
On 9. Sep, 2010, at 15:37 , David Aldrich wrote:
> Hi Michael
>
>> Are they _always_ next to each other and is FolderB always called by that
>> name?
>
> Yes
>
>> If so, just do ${CMAKE_PROJECT_DIR}/../FolderB.
>
> Thanks that worked fine. I wasn't aware of that syntax possibility.
>
> Davi
Hi Michael
> Are they _always_ next to each other and is FolderB always called by that
> name?
Yes
> If so, just do ${CMAKE_PROJECT_DIR}/../FolderB.
Thanks that worked fine. I wasn't aware of that syntax possibility.
David
___
Powered by www.kitwar
On 9. Sep, 2010, at 14:39 , David Aldrich wrote:
> Hi Michael
>
>> With CMake you can use absolute and relative paths, no problem. If you use
>> absolute paths, please use one of the pre-defined variables, such as
>> ${CMAKE_SOURCE_DIR}, ${CMAKE_BINARY_DIR}, ${CMAKE_CURRENT_SOURCE_DIR}
>> ${CMAK
To the best of my knowledge, there is not an easy, cross-platform way to
decompose.
On Wed, Sep 8, 2010 at 11:43 PM, Tim St. Clair wrote:
> I guess a follow on to that would be the opposite to composition. If I
> wanted to decompose a cmake library to determine what object files it
> contains
Hi Michael
> With CMake you can use absolute and relative paths, no problem. If you use
> absolute paths, please use one of the pre-defined variables, such as
> ${CMAKE_SOURCE_DIR}, ${CMAKE_BINARY_DIR}, ${CMAKE_CURRENT_SOURCE_DIR}
> ${CMAKE_CURRENT_BINARY_DIR} ${PROJECT_SOURCE_DIR}, ${PROJECT_BIN
Ryan Pavlik wrote:
> Not sure how you're setting the LDFLAGS, but if you append -fPIE -pie to
> this variable, it should be used only for executables.
>
> http://cmake.org/cmake/help/cmake-2-8-docs.html#variable:CMAKE_EXE_LINKER_F
> LAGS
>
> There is an undocumented peer to this variable, somethi
Not sure how you're setting the LDFLAGS, but if you append -fPIE -pie to
this variable, it should be used only for executables.
http://cmake.org/cmake/help/cmake-2-8-docs.html#variable:CMAKE_EXE_LINKER_FLAGS
There is an undocumented peer to this variable, something like
CMAKE_LIBRARY_LINKER_FLAGS
Hi,
I have a project which builds shared objects and executables on linux. The
goal is to have the library as PIC and the executable as PIE. PIC seems not a
problem as cmake already does it.
There exist a blacklist for architectures which doesn't support PIE well yet
(hppa, m68k, mips, mipsel,
On 9. Sep, 2010, at 11:19 , David Aldrich wrote:
> Hi Michael
>
> The makefile I am replacing uses VPATH to specify a source file that must be
> compiled for the target.
>
> That source file is in a different directory to the one containing
> CMakeLists.txt.
>
> How can I achieve this with C
AFAIK you need full language support for that. So far I haven't seen a good
solution for that problem. CMake definitely needs some reworking there.
Michael
On 9. Sep, 2010, at 11:23 , Benjamin Schindler wrote:
> Hi
>
> Thank you for your quick answer. I had a quick glance - what I don't
> quit
Hi
Thank you for your quick answer. I had a quick glance - what I don't
quite understand is how can I integrate this into my custom cmake
script? I have a ADD_CUSTOM_COMMAND, and in the depends I need this list
of dependent files (the generated files, not the xsd's themselves).
If you could shed
Hi Michael
The makefile I am replacing uses VPATH to specify a source file that must be
compiled for the target.
That source file is in a different directory to the one containing
CMakeLists.txt.
How can I achieve this with CMake please?
Best regards
David
__
On 9. Sep, 2010, at 10:15 , Benjamin Schindler wrote:
> Hi
>
> I've written a cmake script for the codesynthesis xsd compiler which
> works kindof similar to the qt scripts calling moc etc.
> The problem is, that I have no dependency checker. I'd need to parse the
> xsd asked for and put all inc
Hi
I've written a cmake script for the codesynthesis xsd compiler which
works kindof similar to the qt scripts calling moc etc.
The problem is, that I have no dependency checker. I'd need to parse the
xsd asked for and put all included xsd's in to the dependency list. And
this needs to be cross pl
26 matches
Mail list logo
