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 wor
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 c
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:
INST
Cmake provides add_custom_target, but that creates a target that gets
run either always (ALL) or manually by running make .
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 are alway
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 yo
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 ccmak
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 example
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 a
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 mult
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-g
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
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
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
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
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 r
On 17.01.08 11:47:38, Matthias Schweinoch wrote:
> 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
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 cu
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, "D
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 "${CMAKE_INSTA
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).
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 conf
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
shared
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.
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:
SET(CM
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 PR
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 fr
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
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 De
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 cr
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
fil
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 fi
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. g
36 matches
Mail list logo