Dear Developers,
I am a graduate student from University of Maryland Baltimore County.
I have a simple question pertaining to Cmake Development Cycle.
Has Cmake gone under some refactoring efforts before any of its release? If
yes could you please tell me which release was it.
Your res
Dear Developers,
I am a graduate student from University of Maryland Baltimore County.
I have a simple question pertaining to Cmake Development Cycle.
Has Cmake gone under some refactoring efforts before any of its release? If
yes could you please tell me which release was it.
Your res
How does "/install/MacOS/liblibB.dylib" end up in the list of references
that libA depends on if that's not where libB is built?
On Tue, Oct 19, 2010 at 5:14 PM, Marco Nolden
wrote:
> On 10/19/2010 05:47 PM, David Cole wrote:
>
> This likely means that "otool -L" on libA is reporting "
What version are these stock i386 binaries you speak of?
Where did they come from?
For 2.8.1 and earlier the problem did not exist.
For 2.8.2, the problem did exist.
It should be fixed again in 2.8.3-rc2 and later.
On Tue, Oct 19, 2010 at 4:18 PM, Tim St. Clair wrote:
> b4 I do this, because
On 10/19/2010 06:04 PM, Clinton Stimpson wrote:
I would also suggest you use the latest version of cmake or try 2.8.3 RC.
And be sure to include the path to where libB would be in the 3rd
parameter to fixup_bundle().
Clint
We use the latest BundleUtilites and GetPrerequisites scripts from C
On 10/19/2010 05:47 PM, David Cole wrote:
This likely means that "otool -L" on libA is reporting
"/Users/engelm/bundle-test/install/MacOS/liblibB.dylib" as a dependent
library... If that's true, then why doesn't the library exist?
It exists in the build tree but we did not add install commands
b4 I do this, because it's a non-trivial investment on a
non-heterogeneous build cluster, can you explain why the i386 stock
binaries behave differently?
Cheers,
Tim
On Tue, Oct 19, 2010 at 2:58 PM, Bill Hoffman wrote:
> Try the 2.8.3 release candidate.
>
> In 2.8.2 the untar did not preserve fi
Try the 2.8.3 release candidate.
In 2.8.2 the untar did not preserve file times, and this could cause
auto-make to rerun when it really did not need to.
-Bill
On 10/19/2010 3:21 PM, Tim St. Clair wrote:
I've been able to consistently repro an issue using
ExternalProject_Add w/a configure bu
I've been able to consistently repro an issue using
ExternalProject_Add w/a configure build of cmake v.s. the i386
binaries online shows an issue whenever a it tries to call auto-conf
or auto-make as if the environment is hosed. When I use the stock
i386 binaries I do not see this issue and I'm ab
ahh excellent thanx.
On Tue, Oct 19, 2010 at 12:06 PM, Tyler Roscoe wrote:
> On Tue, Oct 19, 2010 at 12:05:21PM -0700, J Decker wrote:
>> WIthout adding a bunch of custom addtions, is there something I can
>> test to see if a target is already defined?
>
> Did you try 'if (TARGET ...)'?
>
> tyler
On Tue, Oct 19, 2010 at 12:05:21PM -0700, J Decker wrote:
> WIthout adding a bunch of custom addtions, is there something I can
> test to see if a target is already defined?
Did you try 'if (TARGET ...)'?
tyler
___
Powered by www.kitware.com
Visit othe
WIthout adding a bunch of custom addtions, is there something I can
test to see if a target is already defined?
What I would like is although this whole project tree can build, I
really want to build sub-projects. That is I have say 15
applications, all sharing a common 15 or so libraries (probab
OK if anyone is tallying how many hours have been wasted on Unicode
files with BOM, add at least one for me.
This is a logged bug for CMake: http://public.kitware.com/Bug/view.php?id=11137
I assume that 2.8.4 or whatever will find a way to deal with this.
But my quick summary is this: A Unicode f
I would also suggest you use the latest version of cmake or try 2.8.3 RC.
And be sure to include the path to where libB would be in the 3rd
parameter to fixup_bundle().
Clint
On 10/19/2010 09:47 AM, David Cole wrote:
This likely means that "otool -L" on libA is reporting
"/Users/engelm/bundl
This likely means that "otool -L" on libA is reporting "
/Users/engelm/bundle-test/install/MacOS/liblibB.dylib" as a dependent
library... If that's true, then why doesn't the library exist?
Do you build libA against a build tree including libB or against an install
tree of libB...?
Yes, that is b
Dear all,
we have some problems using the BundleUtilities macro for deployment on
Mac OS X. I created a very small test project which is similar to our setup:
http://github.com/nolden/bundle-test
- libA is a plugin that would be loaded at runtime by means of dlopen
(or something similar). We
> Please keep follow-up questions on list, so others may participate and
> benefit as well.
Oh, I did not realize that I sent my email off list. I just hit reply,
without double checking the recipient field.
> The Framework test demonstrates one (not pretty, not elegant, but
> possible) way to do
Please keep follow-up questions on list, so others may participate and
benefit as well.
The Framework test demonstrates one (not pretty, not elegant, but possible)
way to do what you want.
Rather than using PUBLIC_HEADER to achieve the final location of the nested
header file, use the source file
On 10/19/2010 4:21 AM, Marcel Loose wrote:
Hi all,
I stumbled upon IMHO weird behaviour of CTest.
It seems that compilation errors are not picked up, somehow. Look at the
output of a run of "ctest -V -D ExperimentalBuild" below.
/export/home/loose/work/LOFAR_trunk/LOFAR/LCS/pyparameterset/src/p
On 19. Oct, 2010, at 10:21 , Marcel Loose wrote:
> Hi all,
>
> I stumbled upon IMHO weird behaviour of CTest.
> It seems that compilation errors are not picked up, somehow. Look at the
> output of a run of "ctest -V -D ExperimentalBuild" below.
>
> /export/home/loose/work/LOFAR_trunk/LOFAR/LCS/
Hi all,
I stumbled upon IMHO weird behaviour of CTest.
It seems that compilation errors are not picked up, somehow. Look at the
output of a run of "ctest -V -D ExperimentalBuild" below.
/export/home/loose/work/LOFAR_trunk/LOFAR/LCS/pyparameterset/src/pyparameterset.cc:22:27:
error: lofar_config.h
On 19. Oct, 2010, at 9:48 , Maik Beckmann wrote:
> 2010/10/19 Michael Wild :
>>
>> While I agree that it should be added to the documentation of find_package,
>> it is what most people would expect (except when they get bitten by it).
>> Most people would be pretty stumped if CMake wouldn't se
2010/10/19 Michael Wild :
>
> While I agree that it should be added to the documentation of find_package,
> it is what most people would expect (except when they get bitten by it). Most
> people would be pretty stumped if CMake wouldn't search in the installation
> prefix.
>
> My 2 cents...
I d
On 19. Oct, 2010, at 9:22 , Maik Beckmann wrote:
> This is not a question but a finding during a debugging session I like to
> share and a documentation enhancement request.
>
> We have a number of projects that reside in different repositories including
> library projects that are chained up
This is not a question but a finding during a debugging session I like
to share and a documentation enhancement request.
We have a number of projects that reside in different repositories
including library projects that are chained up by find_package in
conjunction with -config.cmake files th
25 matches
Mail list logo
