On 8/6/10 8:55 PM, Eric Noulard wrote:
> 2010/8/6 Chris Wolf :
>> Earlier, I identified a problem with the "PackageMaker" (Apple) packager,
>> and now, I see the same exact problem with the "DEB" (Debian)
>> packager - it keeps prefixing "./usr" to all the paths.
>>
>> Changing CPACK_PACKAGING_IN
2010/8/6 Chris Wolf :
> Earlier, I identified a problem with the "PackageMaker" (Apple) packager,
> and now, I see the same exact problem with the "DEB" (Debian)
> packager - it keeps prefixing "./usr" to all the paths.
>
> Changing CPACK_PACKAGING_INSTALL_PREFIX doesn't do anything
> (even when it
On 8/6/10 8:43 PM, Eric Noulard wrote:
> 2010/8/6 Chris Wolf :
>> I am trying the ZIP package type and I get the same error on MacOS and Linux:
>>
>> CPack Error: archive_write_header:Filetype not supportedNo such file or
>> directory -25
>> CPack Error: archive_write_data(): tried to write 1638
Ok, I finally figured this out. I needed to set set(CPACK_SET_DESTDIR true)
so that CMAKE_INSTALL_PREFIX overrides the default prefix of "./usr" baked into
PackageMaker and DEB generators.
CPACK_PACKAGING_INSTALL_PREFIX is a total "red herring" - who knows what
that's for? ;)
BTW, I led to the s
2010/8/6 Chris Wolf :
> I am trying the ZIP package type and I get the same error on MacOS and Linux:
>
> CPack Error: archive_write_header:Filetype not supportedNo such file or
> directory -25
> CPack Error: archive_write_data(): tried to write 16384
> write 0
>
>
> I searched around in case this
2010/8/7 Jashank Jeremy :
> Hi,
>
> I'm working on a project that requires an additional module, which is
> shipped with the project, but I'd like CMake to add CMAKE_SOURCE_PATH
> to CMAKE_MODULE_PATH to pick up the additional module.
>
> I've tried adding
>
> set(CMAKE_MODULE_PATH "${CMAKE_SOURCE_
On 8/6/10 6:30 PM, David Cole wrote:
> On Fri, Aug 6, 2010 at 5:49 PM, Chris Wolf wrote:
>
>> I'm still unclear what you're suggesting here (quote, below). If
>> I run "make package", doesn't that make target invoke cpack with the
>> cmake-generated cpack options file (CPackConfig.cmake)?
>>
>
Hi,
I'm working on a project that requires an additional module, which is
shipped with the project, but I'd like CMake to add CMAKE_SOURCE_PATH
to CMAKE_MODULE_PATH to pick up the additional module.
I've tried adding
set(CMAKE_MODULE_PATH "${CMAKE_SOURCE_PATH}:${CMAKE_MODULE_PATH}")
to my CMak
On Fri, Aug 6, 2010 at 5:49 PM, Chris Wolf wrote:
> I'm still unclear what you're suggesting here (quote, below). If
> I run "make package", doesn't that make target invoke cpack with the
> cmake-generated cpack options file (CPackConfig.cmake)?
>
> ...and isn't "cpack --config CPackConfig.cmake
I'm still unclear what you're suggesting here (quote, below). If
I run "make package", doesn't that make target invoke cpack with the
cmake-generated cpack options file (CPackConfig.cmake)?
...and isn't "cpack --config CPackConfig.cmake" equivalent?
Also, nowhere in the ./share/cmake-2.8.2/Modul
Bill,
I have been in contact with tech support at Bullseye. They have been able
to reproduce this problem with covbr. They found that the issue started
with version 7.14.6 . They said they will let me know when they have a fix.
I was able to reproduce this issue with covbr with a simple Visua
I think Ryan's comments help support my assessment of FindWhatevers. Add
recently downloaded GTK in GLade 3.6 for windows and can now add this to
list of not working FindWhatevers. find_package( GTK2 ) of course does not
work for this as of today.
Statements like
"CAUTION: The contents of this
>From your suggestions, I tried a shortcut:
cpack -D CPACK_PACKAGE_DEFAULT_LOCATION=/tmp/local
...but this didn't work either. I will delve further into
the CPack options-file approach.
Thanks,
-Chris
On 8/6/10 4:52 PM, David Cole wrote:
> You need a CPackOptions file (CPACK_PROJECT_CONF
On 8/6/2010 3:45 PM, Derek Minton wrote:
Bill,
I get the same error with covbr on Bullseye 7.14.9. It gives an error
that it cannot open the source file(s). I can report this discrepancy
between 7.14.0 and 7.14.9 to Bullseye and see what they have to say.
Yes, please do. It looks like c
You need a CPackOptions file (CPACK_PROJECT_CONFIG_FILE) that gets loaded at
CPack time.
In CMake, ours has this at the bottom of it:
if("${CPACK_GENERATOR}" STREQUAL "PackageMaker")
if(CMAKE_PACKAGE_QTGUI)
set(CPACK_PACKAGE_DEFAULT_LOCATION "/Applications")
else(CMAKE_PACKAGE_QTGUI)
Earlier, I identified a problem with the "PackageMaker" (Apple) packager,
and now, I see the same exact problem with the "DEB" (Debian)
packager - it keeps prefixing "./usr" to all the paths.
Changing CPACK_PACKAGING_INSTALL_PREFIX doesn't do anything
(even when it's at the top of the file)
This
On 08/06/2010 04:22 PM, Verweij, Arjen wrote:
> I did it is below the cmake error in the previous email. No error just a
> prompt
> And no noticeable difference to me.
Your previous message did
E:\cmake28\bin\cmake.exe -E vs_link_exe
E:\PROGRA~1\Intel\Compiler\Fortran\9.1\em64t\bin\ifort.exe /
On Fri, 2010-08-06 at 08:56 -0700, Tyler Roscoe wrote:
> On Thu, Aug 05, 2010 at 09:26:05PM -0500, Frank Gruman wrote:
> > The problem - dependencies. Each build is supposed to be independent
> > of any other. S:
> >
> > Build Project A-1
> > Depends on B-1
> > Depends on C-3
> >
I am trying the ZIP package type and I get the same error on MacOS and Linux:
CPack Error: archive_write_header:Filetype not supportedNo such file or
directory -25
CPack Error: archive_write_data(): tried to write 16384
write 0
I searched around in case this was a known issue. The Wiki says:
"
I did it is below the cmake error in the previous email. No error just a prompt
And no noticeable difference to me.
Arjen
>-Original Message-
>From: Brad King [mailto:brad.k...@kitware.com]
>Sent: vrijdag 6 augustus 2010 21:39
>To: Verweij, Arjen
>Cc: cmake@cmake.org
>Subject: Re: [CM
On 8/6/10 12:57 PM, Chris Wolf wrote:
>
>
> On 8/6/10 7:22 AM, Eric Noulard wrote:
>> 2010/8/6 Chris Wolf :
>>>
>>> e.g for : install(TARGETS usb LIBRARY DESTINATION lib)
>>>
>>> (where project name is "libusb")
>>>
>>> The CPack-generated TGZ archive will contain:
>>> libusb-0.1.1-Darwin/lib/
The alternative to this hardcoding is, if the find module is broken
for the "standard" system, fix it and submit a patch (a lot are only
minimally maintained and most are at least outdated stylewise), or if
you know your lib is in a weird place on your system, append that
location to CMAKE_PRE
Bill,
I get the same error with covbr on Bullseye 7.14.9. It gives an error
that it cannot open the source file(s). I can report this discrepancy
between 7.14.0 and 7.14.9 to Bullseye and see what they have to say.
-Derek
-Original Message-
From: cmake-boun...@cmake.org [mailto:cma
On 8/6/2010 2:38 PM, Derek Minton wrote:
Bill,
Sorry about the confusion. Disregard my last post concerning this issue.
I thought I had 7.14.9 installed but I was still running 7.14.0. I will
install 7.14.9 and let you know if covbr works.
7.14.10 is the one that seems to fail for me.
On 08/06/2010 03:12 PM, Verweij, Arjen wrote:
> it does get recognized as Intel.
[snip]
> -- The Fortran compiler identification is Intel
Good.
> I started again, and included the manual link line. The rsp file exists
> and contains CMakeFiles/cmTryCompileExec.dir/testFortranCompiler.f.obj,
> the
On 8/6/10 12:44 PM, John McGehee wrote:
Um, yes, that would be it. I copied the values for
CMAKE_C_FLAGS_DEBUG , CMAKE_C_FLAGS_RELEASE, et al. verbatim from
somewhere on the Internet, and they all contained the /Tc options.
Once I removed them, the compiler runs.
Thanks, Ryan. Sometimes I
On 8/6/10 1:12 PM, Magnus Therning wrote:
I was trying to put something like this into a CMake file:
add_custom_command( ...
COMMAND ...
COMMAND ([[ -f foo ]] || ln -sf foo bar); true
)
But CMake won't have it. Skipping the sub-shell is all right with CMake:
add_custom_command
Hi Brad,
Uh, I don't know how that happened. I pulled a fresh copy of the initial
virtual machine, it does get recognized as Intel. I started again, and included
the manual link line. The rsp file exists and contains
CMakeFiles/cmTryCompileExec.dir/testFortranCompiler.f.obj, the tmp file is
no
Bill,
Sorry about the confusion. Disregard my last post concerning this issue.
I thought I had 7.14.9 installed but I was still running 7.14.0. I will
install 7.14.9 and let you know if covbr works.
-Derek
-Original Message-
From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake
Bill,
I am able to run covbr on my system with Bullseye 7.14.9. I do get
detailed source coverage info in the output but I am not familiar enough
with the exact expected output format to know if it differs from what CMake
expects. The output looks reasonable in that it has source names and
de
I was trying to put something like this into a CMake file:
add_custom_command( ...
COMMAND ...
COMMAND ([[ -f foo ]] || ln -sf foo bar); true
)
But CMake won't have it. Skipping the sub-shell is all right with CMake:
add_custom_command( ...
COMMAND ...
COMMAND [[ -f foo ]] |
On 8/6/2010 9:49 AM, Bill Hoffman wrote:
Thanks for the report I will have to take a look
They must have changed something...
If you want to help, the code is pretty simple, it is all in this function:
Source/CTest/cmCTestCoverageHandler.cxx:
int cmCTestCoverageHandler::RunBullseyeCover
Um, yes, that would be it. I copied the values for CMAKE_C_FLAGS_DEBUG ,
CMAKE_C_FLAGS_RELEASE, et al. verbatim from somewhere on the Internet, and they
all contained the /Tc options. Once I removed them, the compiler runs.
Thanks, Ryan. Sometimes I just need someone to look over my shoulder.
On 8/6/10 9:46 AM, Bill Hoffman wrote:
> There is one in the Tutorial:
>
> http://www.cmake.org/cmake/help/cmake_tutorial.html
>
> -Bill
I did look at that when I first started, but this tutorial
does not install the library (just the executable and headers).
Right now, I'm focused on a proje
On 8/6/10 7:22 AM, Eric Noulard wrote:
> 2010/8/6 Chris Wolf :
>>
>> e.g for : install(TARGETS usb LIBRARY DESTINATION lib)
>>
>> (where project name is "libusb")
>>
>> The CPack-generated TGZ archive will contain:
>> libusb-0.1.1-Darwin/lib/libusb.dylib
>>
>> ...this, regardless of the setting
>
> 2010/7/27 Eric Noulard :
> > Here comes a proposal for a bash completion for cmake.
Awesome. Thanks a lot for submitting this.
Works great here on gentoo.
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kit
On Thu, Aug 05, 2010 at 09:26:05PM -0500, Frank Gruman wrote:
> The problem - dependencies. Each build is supposed to be independent
> of any other. S:
>
> Build Project A-1
> Depends on B-1
> Depends on C-3
>
> Build Project A-2
> Depends on B-3
> Depends on C-3
>
>
On 08/06/2010 11:26 AM, Verweij, Arjen wrote:
> I can execute the linkline manually and it seems to link fine.
> How can I debug what's going on?
[snip]
> -- The Fortran compiler identification is unknown
This is the first problem which may cause the others. CMake does not
recognize the compiler
Fails miserably on Win32 (XP), Win7 64, Win Server 2008 64 too. You'll find
as I have that the "find whatevers" are not all that they are cracked up to
be. CUDA is another example. find_package should really be named
attempt_to_find_package_and_when_you_can't_simply_tell_me_the_vars_to_set(
pack
Hi,
Ifort 9.1 is unable to compile a simple test program on WinXP 64 bit with cmake
2.8.2.
I can execute the linkline manually and it seems to link fine.
How can I debug what's going on?
Thanks,
Arjen
E:\build>cmake Z:\f90example -G "NMake Makefiles" --debug-trycompile
debug trycompile on
--
There is one in the Tutorial:
http://www.cmake.org/cmake/help/cmake_tutorial.html
-Bill
___
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 ch
On 8/5/2010 5:07 PM, Derek Minton wrote:
I have a CMake 2.8.2 based project that is using Bullseye Coverage and
Visual Studio 10 along with CTest on Windows 7 64bit. This project is
reporting building/testing/coverage results to a local CDash server. If I
use Bullseye 7.14.0 the coverage res
Are you adding /Tc to the flags anywhere in your build? (either incorrectly
with add_definitions, or correctly with set cmake_c_flags?)
Ryan
On Thu, Aug 5, 2010 at 9:16 PM, John McGehee wrote:
> I have my CMake build, test and install working on Linux, and now I'm
> trying to get it to build on
2010/8/6 Chris Wolf :
>
> e.g for : install(TARGETS usb LIBRARY DESTINATION lib)
>
> (where project name is "libusb")
>
> The CPack-generated TGZ archive will contain:
> libusb-0.1.1-Darwin/lib/libusb.dylib
>
> ...this, regardless of the setting of CPACK_INCLUDE_TOPLEVEL_DIRECTORY!
>
> (I would ha
Is the FindMatlab.cmake package maintained? It seems to fail miserably on
Mac.
Are there any patches out there?
Thanks for any tips...
James
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/o
45 matches
Mail list logo
