On Thu, May 1, 2014 at 6:35 PM, Graham Russell wrote:
> Seems like there are 2 choices for a solution:
> 1. Change CMake so it uses the IBM linker instead of the GNU linker.
> What settings would I need to change in the cmake files to try this?
>
This is not really an option. CMake can not c
Seems like there are 2 choices for a solution:
1. Change CMake so it uses the IBM linker instead of the GNU linker. What
settings would I need to change in the cmake files to try this?
2. Change the linker options so they will work for the GNU linker.
I tried option #2 by removing "-bnoipath
On 5/1/2014 4:04 PM, Graham Russell wrote:
Thanks for the response, Bill.
I confirmed that the compiler install works fine:
pvm-vangogh-94:grussell [625] /usr/local/bin/gcc hello.c -o hello
pvm-vangogh-94:grussell [626] ./hello Hello World!
I also tested it with your simple program and it als
Thanks for the response, Bill.
I confirmed that the compiler install works fine:
pvm-vangogh-94:grussell [625] /usr/local/bin/gcc hello.c -o hello
pvm-vangogh-94:grussell [626] ./hello Hello World!
I also tested it with your simple program and it also compiles OK and runs.
I think the problem
Ugh ! It gets messier. I'm beginning to understand why it is the way it
is. The cmake developers have probably already been round this loop and
decided it wasn't worth the effort :-)
On 1 May 2014 19:41, Nils Gladitz wrote:
> On 01.05.2014 20:38, Glenn Coombs wrote:
>
>> Okay, I think I unde
On 01.05.2014 20:38, Glenn Coombs wrote:
Okay, I think I understand what you're saying. Variables set in a
CMakeLists.txt file added by add_subdirectory are only visible in that
CMakeLists.txt and any further ones it adds via add_subdirectory. The
higher level CMakeLists.txt files would not h
Okay, I think I understand what you're saying. Variables set in a
CMakeLists.txt file added by add_subdirectory are only visible in that
CMakeLists.txt and any further ones it adds via add_subdirectory. The
higher level CMakeLists.txt files would not have the necessary visibility,
hence the need
On 2014-05-01 14:26, Nils Gladitz wrote:
On 01.05.2014 20:16, Matthew Woehlke wrote:
If CMAKE_BINARY_DIR were not cached, yes. But I don't think not
caching that is being suggested. It's not clear to me why the
*per-project* flavors need to be cached?
If they were regular instead of cache var
On Thu, May 1, 2014 at 11:26 AM, Nils Gladitz wrote:
> On 01.05.2014 20:16, Matthew Woehlke wrote:
>
>>
>> If CMAKE_BINARY_DIR were not cached, yes. But I don't think not caching
>> that is being suggested. It's not clear to me why the *per-project* flavors
>> need to be cached?
>>
>>
> If they w
I turned off all virus and spam software and that did not do it either. I am
lost here, I have no idea what to do anymore. Any help from anyone would be
greatly appreciated!
Thanks,
Eric
From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Eric Clark
Sent: Thursday, May 01, 2014 12:07 PM
T
On 01.05.2014 20:16, Matthew Woehlke wrote:
If CMAKE_BINARY_DIR were not cached, yes. But I don't think not
caching that is being suggested. It's not clear to me why the
*per-project* flavors need to be cached?
If they were regular instead of cache variables they would have scopes.
I guess
On Thu, May 1, 2014 at 2:16 PM, Matthew Woehlke
wrote:
> On 2014-05-01 13:35, John Drescher wrote:
>>>
>>> I thought they probably were. My question was really if the behaviour
>>> that
>>> results from that was desirable. I can't see any reason why they should
>>> be
>>> cached as they aren't u
On 2014-05-01 13:35, John Drescher wrote:
I thought they probably were. My question was really if the behaviour that
results from that was desirable. I can't see any reason why they should be
cached as they aren't user configurable variables. Would it break anything
badly if they were not stor
On Thu, May 1, 2014 at 1:54 PM, Glenn Coombs wrote:
> What I am saying is that project("foo") should internally execute the
> equivalent of set(foo_SOURCE_DIR "/path/to/source") rather than set(foo
> "/path/to/source" CACHE STRING). That way it would fail on every run if you
> referenced a projec
What I am saying is that project("foo") should internally execute the
equivalent of set(foo_SOURCE_DIR "/path/to/source") rather than set(foo
"/path/to/source" CACHE STRING). That way it would fail on every run if
you referenced a project source directory variable before you had done the
add_subdi
> I thought they probably were. My question was really if the behaviour that
> results from that was desirable. I can't see any reason why they should be
> cached as they aren't user configurable variables. Would it break anything
> badly if they were not stored in the cache ? It would result i
I thought they probably were. My question was really if the behaviour that
results from that was desirable. I can't see any reason why they should be
cached as they aren't user configurable variables. Would it break anything
badly if they were not stored in the cache ? It would result in more
c
On 5/1/2014 12:30 PM, Graham Russell wrote:
Hello
I installed cmake 2.8.12.2 on AIX 6.1 with the intention of building
MySQL. The build fails so I tried to cmake the simplest test program,
and I get the same failure.
The error is “ld: target noipath not found”
It seems to me that “noipath” i
That is an idea, except that this just happened again with the parallel project
builds turned down to 1 and the /MP option not set. And the file that was being
copied was not even created by the build. Instead, the file is one that is
being copied from another location: QtSql4.dll. This particul
On 01.05.2014 19:00, Eric Clark wrote:
Well, that is what I was thinking, so I turned off the /MP option and
that did not help. The next thing that I was going to try was to set
the number of parallel project builds to 1 instead of the default 8.
If this works, it would seem like the post-bui
Hello
I installed cmake 2.8.12.2 on AIX 6.1 with the intention of building MySQL.
The build fails so I tried to cmake the simplest test program, and I get the
same failure.
The error is "ld: target noipath not found"
It seems to me that "noipath" is a directive to the linker, so the linker
s
Well, that is what I was thinking, so I turned off the /MP option and that did
not help. The next thing that I was going to try was to set the number of
parallel project builds to 1 instead of the default 8. If this works, it would
seem like the post-build step is not part of the build of that p
On 01.05.2014 18:32, Eric Clark wrote:
12>PostBuildEvent:
12> -- Install configuration: "Debug"
12> -- Install component: "development"
12> -- Installing: C:/projects/AraFramework/bin/AraOpenGLd.dll
12> CMake Error at cmake_install.cmake:64 (FILE):
12>file INSTALL cannot set modific
Hello,
I have a few Visual Studio projects that I set a post-build event in Visual
Studio to copy the DLLs, LIBs and a few other files up into a directory used
for development. I do this by running the following custom command:
add_custom_command(TARGET ${PROJECT_NAME} POST_BUILD COMMAND
On 01.05.2014 16:57, Rick McGuire wrote:
I was able to build the project with these steps:
- Open the "VS2013 x64 Cross Tools Command Prompt"
This is not something I'm familiar with...where do I find this? Also,
if this is something only available if you have the full Visual Studio
i
On 01.05.2014 15:54, Rick McGuire wrote:
Is it possible to get cmake to check the actual compile/link commands
when they are issued? I'd love to compare the cmake versions to our
existing build to see if things are ending up the same.
To a degree (response files on window limit the output i
On 01.05.2014 15:13, Rick McGuire wrote:
"clean build" referred to our existing system, not the cmake
conversion. For our current system, it is only necssary to nuke the
build output directory. Figuring out the mechanics of doing a
switching mode under cmake is something we'll deal with once
"clean build" referred to our existing system, not the cmake conversion.
For our current system, it is only necssary to nuke the build output
directory. Figuring out the mechanics of doing a switching mode under
cmake is something we'll deal with once we're able to get the different
kinds of bui
On 01.05.2014 15:04, Rick McGuire wrote:
With our existing setup, to switch between 32- and 64- bit builds, we
only need to change the option specified on the vcvarsall batch file
and do a clean build. The tools figure out from the environment
variables which build we're doing any everything
We're trying to convert a project from using a very old hand-built makefile
(the original version was written over 20 years ago!) to using cmake. We
want to do the builds using command line nmake, not using Visual Studio
project files.
With our existing setup, to switch between 32- and 64- bit bu
30 matches
Mail list logo
