Hy!
I want to build a database library for different oracle versions from one
source.
The pl/sql code should be compiled once by proC from Oracle 9 and by proC from
Oracle 10.
Therefore I defined different targets and tried to define the proC compiler
with target properties
but this doesn't
On 17.01.08 09:15:46, [EMAIL PROTECTED] wrote:
I want to build a database library for different oracle versions from one
source.
The pl/sql code should be compiled once by proC from Oracle 9 and by proC
from Oracle 10.
Therefore I defined different targets and tried to define the proC
Hi,
I use use CPack to generate multiple packages (abusing COMPONENT).
My project dirs are like that:
Libs/
ProjectA/
ProjectB/
ProjectA and B need the libs from Libs. So when I create a package for
ProjectA / ProjectB I need the packaging to include libs from Libs.
So in Libs/CMakeLists.txt:
Cmake provides add_custom_target, but that creates a target that gets
run either always (ALL) or manually by running make target.
Cmake also provides an add_custom_command that tracks file dependencies
and gets run when a dependency changes. However, add_custom_command
assumes the files
On Jan 17, 2008 5:10 AM, Gonzalo Garramuño [EMAIL PROTECTED] wrote:
Is there a way to create an add_custom_target that tracks dependencies?
Or an add_custom_command that will act as a target (without needlessly
being added to add_executable, etc).
To get the effect of that, you wrap your
Hi all,
I'm a new cmake user and I'm having a little trouble. Perhaps someone here can
help me: I was wondering if it is possible to specify a build path manually
within the toplevel CMakeLists.txt file? I did read the wiki about
out-of-source build environments, but the examples all used
Hi Matthias,
I'm a new cmake user and I'm having a little trouble. Perhaps
someone here can help me: I was wondering if it is possible
to specify a build path manually within the toplevel
CMakeLists.txt file? I did read the wiki about out-of-source
build environments, but the examples
Hello,
We're migrating a large project from MSVC6.0 to CMake, still building
with .dsps for MSVC6.0 generated by Cmake. One of the projects uses two
different def file to export its symbols, one for debug builds the other
for release builds. This is currently achieved using the project
setting
Brandon Van Every wrote:
Admittedly this is inelegant, but it works. I have no idea how much
work it would be to remove the distinction between file level and
target level dependencies.
It isn't inelegant, but quite logical. It probably should be kept as
is, as it allows easily adding
Despite what it says in the Wiki, Visual C++ 2008 Express does not work
nicely with cmake for me.
I have cmake 2.4 patch 7, which I believe is the current release for
Windows. As it does not offer a generator option for VC9, I selected
VC8/2005.
Then initial configuration fails because Visual
Eric Noulard escreveu:
I think that when you build a gcc cross compiler you end up
with the i486-linux-gnu-gcc kind of naming scheme I don't
know if it's standard or not but...
Well, I every linux distribution I know the gcc install target ends up
creating symlinks like i686-pc-linux-gnu-gcc -
On 17.01.08 14:21:16, [EMAIL PROTECTED] wrote:
Now I'm about to abandon using cmake.
I can't find a way to examine the different targets in a variable.
I made the different builddirs by defining subdirs:
ADD_LIBRARY(ora9i/libora ...
ADD_LIBRARY(ora10g/libora ...
and now?
Thats not a
Now I'm about to abandon using cmake.
I can't find a way to examine the different targets in a variable.
I made the different builddirs by defining subdirs:
ADD_LIBRARY(ora9i/libora ...
ADD_LIBRARY(ora10g/libora ...
and now?
The problem is that I want to build both configurations simultaneously.
2008/1/17, Rodolfo Lima [EMAIL PROTECTED]:
Eric Noulard escreveu:
#!/bin/sh
distcc i686-pc-linux-gnu-gcc $@
called gcc. This works well and should be IMHO proposed to distcc
developers because it deals with cmake's way to invoking gcc.
Ok now I understand you don't don't even want the user
2008/1/17, Rodolfo Lima [EMAIL PROTECTED]:
Well, so redhat is doing something different than the rest. If you
compile and install gcc directly from the official tarball, it'll create
the i686-pc-linux-gnu symlink.
Please try to invoke 'gcc -dumpmachine'. In my gentoo box, it outputs
Eric Noulard escreveu:
No so sure for every linux distro,
since on my fedora 7 i686 box I have:
arch is telling that the host is I686
but the only mangled gcc compiler is called
'i386-redhat-linux-gcc' which is a symlink to ccache.
and there is no 'i686-pc-linux-gnu'.
And I have no
Eric Noulard escreveu:
2008/1/17, Rodolfo Lima [EMAIL PROTECTED]:
Well, so redhat is doing something different than the rest. If you
compile and install gcc directly from the official tarball, it'll create
the i686-pc-linux-gnu symlink.
Please try to invoke 'gcc -dumpmachine'. In my gentoo
Oh, sorry. Rereading your mail message more closely, you want a $
character to pass through properly.
Did you try $$ in the original code (not the one with the single quotes)?
SET(CMAKE_INSTALL_RPATH
${CMAKE_INSTALL_RPATH}:$$ORIGIN/../xxx)
Or perhaps other stuff like on this recent
James,
The lack of braces was deliberate - the $ORIGIN string is not a
CMake variable but a special token that should be passed to the
linker without any expansion (the Linux linker provides special
handling for rpath components that use $ORIGIN).
Regards,
Iker
CMake expands variables with
On Jan 17, 2008 7:46 AM, Gonzalo Garramuño [EMAIL PROTECTED] wrote:
That feature is, however, undocumented. Neither of the add_custom_* nor
the wiki has any mention of this or the possibility of add_custom_target
being able to take a custom command.
Not true. add_custom_target says,
On Jan 17, 2008, at 10:22 AM, Iker Arizmendi wrote:
I did try $$ and it helps, but not always (see the end of
the original post). The problem is that $ symbols that are
I asked if you had tried various permutations of escapes with the
original command [SET(CMAKE_INSTALL_RPATH
On Wednesday 16 January 2008, Pau Garcia i Quiles wrote:
Quoting Alexander Neundorf [EMAIL PROTECTED]:
...
I'm sorry but I think I have not understood what target_use_package is
useful for. Say my system has a /usr/lib/libbar.so. It just works for
me if I do target_link_library(foo bar). What
Thomas Sharpless wrote:
Despite what it says in the Wiki, Visual C++ 2008 Express does not
work nicely with cmake for me.
I have cmake 2.4 patch 7, which I believe is the current release for
Windows. As it does not offer a generator option for VC9, I selected
VC8/2005.
Then initial
I don't have time to help very much right now, but I can point you to this
variable:
CPACK_INSTALL_CMAKE_PROJECTS
grep the CMake source code and read the comments surrounding use of that
variable, and see the ParaView3 source tree for one example of its use.
It's a list of quadruplets that helps
I did try $$ and it helps, but not always (see the end of
the original post). The problem is that $ symbols that are
part of the _value_ of the CMake *_LINKER_FLAGS variables
are treated using rules that aren't clear at all (at least
to me). On my system, a single $ is all that's needed for
On Thursday 17 January 2008, Eric Noulard wrote:
2008/1/16, Filipe Sousa [EMAIL PROTECTED]:
Ted Berg wrote:
Filipe Sousa wrote:
I aplogize, my initial post wasn't terribly clear. I'm currently
generating, for example, the following packages:
foo-sdk-1.0.0.zip
Sorry, I should have been clearer in my last post. I also
tried escaping the value I put into CMAKE_INSTALL_RPATH but
CMake successfully fought me off. Below are some of the
results for an installed executable. Each SET is followed
by the rpath that actually made it to the executable:
Did you try \\\$?
Both $ and \ need escaping inside the CMake set statement so that you end up
with \$ in the variable's value...
And if it goes through another round of CMake substitution, you may even
need something crazy like:
\\\$
HTH,
David
On 1/17/08, Iker Arizmendi [EMAIL
Bill Hoffman wrote:
Sean McBride wrote:
On 1/15/08 9:59 AM, Mike Jackson said:
CMake also supports building 4-way fat by specifying
i386;ppc;ppc64;x86_64.
I have added a FAQ for this here:
http://www.cmake.org/Wiki/CMake_FAQ#Platform-specific_questions
If anyone wants to add more feel
On 14.01.08 23:40:39, Andreas Schneider wrote:
Rodolfo Schulz de Lima wrote:
Hi, I'd like to comment on the Find*.cmake variable naming procedure
adopted by cmake. Right now I have to look at some Find*.cmake files to
see what are the output variables they create. Some packages create a
Even easier, you just check for symlinks at /usr/bin and ~/bin and if they're not there,
ask the user if they want to install for all terminal users / just this terminal
user on app launch and ask for creds if needed.
+ poppy
/me is searching cmake backlog...
Brandon Van Every wrote:
On Dec
Andreas Pakulat wrote:
On 14.01.08 23:40:39, Andreas Schneider wrote:
Rodolfo Schulz de Lima wrote:
Hi, I'd like to comment on the Find*.cmake variable naming procedure
adopted by cmake. Right now I have to look at some Find*.cmake files to
see what are the output variables they create. Some
On Jan 17, 2008, at 5:41 PM, Andreas Schneider wrote:
Andreas Pakulat wrote:
On 14.01.08 23:40:39, Andreas Schneider wrote:
Rodolfo Schulz de Lima wrote:
Hi, I'd like to comment on the Find*.cmake variable naming
procedure
adopted by cmake. Right now I have to look at some Find*.cmake
Hi, I wonder if it's possible to add_custom_command create a temporary
variable which contents are all dependencies of the custom command. This
could be used if one command shall contain all dependencies in its
command line. gnu make does that with $^ (i think). Something similar
with the output
On Jan 17, 2008 9:15 PM, Rodolfo Lima [EMAIL PROTECTED] wrote:
Hi, I wonder if it's possible to add_custom_command create a temporary
variable which contents are all dependencies of the custom command. This
could be used if one command shall contain all dependencies in its
command line. gnu
35 matches
Mail list logo
