I have a program that uses the Window's Event Log. Using the event log is
a little goofy; it requires a message resource file. So I set up a custom
command to call mc.exe can create a header and resource file from a
message script (*.mc file). This generally works fine, but sometimes it
says it
The following variables exist for passing parameters to
check_c_source_compiles:
CMAKE_REQUIRED_FLAGS
CMAKE_REQUIRED_DEFINITIONS
CMAKE_REQUIRED_INCLUDES
CMAKE_REQUIRED_LIBRARIES
Why do we not have CMAKE_REQUIRED_LINK_DIRECTORIES or some such equivalent?
On Unix I can make the check_c_source_com
On 5/6/2010 1:39 PM, Eskandar Ensafi wrote:
Hi all,
To clarify, my concern was not that a 32-bit CMake would not be able to
build a 64-bit application, nor was I worried about the performance.
Rather, considering that it is possible to build a 64-bit CMake, why is it
that the CMake website does
Richard Wackerbarth wrote:
> See RogueResearch6 and Chameleon00.NFSNet.
> Both of these machines are reporting errors for some time.
This should fix the Architecture test:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4d653fb4
It was actually passing but the regex to know that was not
mat
On Thursday 06 May 2010, Jed Brown wrote:
> On Thu, 6 May 2010 18:16:14 +0200, Michael Wild wrote:
> > Another issue: How would one automatically rerun CMake when one of the
> > input files to CMake changes? Of course, the build would then have to
> > continue with the potentially modified Tupfile
On 5/6/2010 12:59 PM, Jed Brown wrote:
Rebuilding with modified Tupfiles is not a problem, and will only build
what is necessary. But:
Tup doesn't support generating the Tupfiles themselves from other
programs. If you do that, you would need to run a separate program to
generate them
Hi,
I'm currently trying to solve a two problems with the RPM generator:
* Lack of support for file names containing spaces
* Lack of support for %config and %config(noreplace)
I'm yet to succeed. I tried to fix the call to sed to enclose file names
between double quotes. It's not working as
Hi all,
To clarify, my concern was not that a 32-bit CMake would not be able to
build a 64-bit application, nor was I worried about the performance.
Rather, considering that it is possible to build a 64-bit CMake, why is it
that the CMake website does not provide a ready built 64-bit native
binary
My understanding of dashmacmini4 is that it isn't 64bit. If I download a
64bit app onto it, it will show a cross symbol through the app icon and
display errors that this architecture is not supported if you attempt to run
it. It was originally a Leopard machine that was upgraded. I think when you
d
>> Error running cmake::LoadCache(). Aborting.
If I did correctly, when i ran the downloaded binary ccmake, why did I
get the above error message?
Zhuang
>
> On Thu, May 6, 2010 at 5:29 AM, Bill Hoffman wrote:
>> On 5/5/2010 11:42 PM, Zhuang Song wrote:
>
> I tried to run linux binary
On Thu, 6 May 2010 18:16:14 +0200, Michael Wild wrote:
>
> Another issue: How would one automatically rerun CMake when one of the
> input files to CMake changes? Of course, the build would then have to
> continue with the potentially modified Tupfile's...
Rebuilding with modified Tupfiles is not
But they are not failing on dashmacmini4.kitware.
My point is that we need to be using and testing as many viable configurations
as possible BEFORE "older" configurations become obsolete. IMHO, encouraging
the widest possible adoption of the "newer" configurations helps in this effort.
Even wit
On Thu, 6 May 2010 11:45:21 -0500, Richard Wackerbarth said:
>See RogueResearch6 and Chameleon00.NFSNet.
>Both of these machines are reporting errors for some time.
The failing 'Architecture' test on Rogue6 fails on _both_ 32 and 64 bit
though.
--
___
See RogueResearch6 and Chameleon00.NFSNet.
Both of these machines are reporting errors for some time.
Richard
On May 6, 2010, at 9:12 AM, Sean McBride wrote:
>
> On Thu, 6 May 2010 08:36:41 -0500, Richard Wackerbarth said:
>
>> Yes, it works for now. However, the 64-bit version for MacOSX 10.6
Another issue: How would one automatically rerun CMake when one of the input
files to CMake changes? Of course, the build would then have to continue with
the potentially modified Tupfile's...
Michael
___
Powered by www.kitware.com
Visit other Kitwar
On Thu, 6 May 2010 17:41:45 +0200, Michael Wild wrote:
>
> On 6. May, 2010, at 17:37 , Jed Brown wrote:
>
> > On Thu, 6 May 2010 17:32:28 +0200, Michael Wild wrote:
> >> Ugh, yes. So this should be (does tup accept absolute source file paths?)
> >>
> >> /path/to/a.f90 |> gfortran -c -o %o %f |
On 6. May, 2010, at 17:37 , Jed Brown wrote:
> On Thu, 6 May 2010 17:32:28 +0200, Michael Wild wrote:
>> Ugh, yes. So this should be (does tup accept absolute source file paths?)
>>
>> /path/to/a.f90 |> gfortran -c -o %o %f |> %B.o %B.mod
>
> No problem on the source paths, but I think this sh
On Thu, 6 May 2010 17:32:28 +0200, Michael Wild wrote:
> Ugh, yes. So this should be (does tup accept absolute source file paths?)
>
> /path/to/a.f90 |> gfortran -c -o %o %f |> %B.o %B.mod
No problem on the source paths, but I think this should be
/path/to/a.f90 |> gfortran -c -o %B.o %f |> %
On 6. May, 2010, at 16:55 , Jed Brown wrote:
> On Thu, 6 May 2010 16:42:13 +0200, Michael Wild wrote:
>> Looks like the Fortran 90 issue can be solved with "order-only" inputs:
>>
>> a.f90 |> gfortran -c -o %o %f |> %f.o
>
> This line also produces a.mod.
Ugh, yes. So this should be (does tup
On Thu, 6 May 2010 16:42:13 +0200, Michael Wild wrote:
> Looks like the Fortran 90 issue can be solved with "order-only" inputs:
>
> a.f90 |> gfortran -c -o %o %f |> %f.o
This line also produces a.mod.
> b.f90 | a.f90 |> gfortran -c -o %o %f |> %f.o
Maybe you meant
b.f90 | a.mod |> gfortran
On 6. May, 2010, at 16:45 , Jed Brown wrote:
> On Thu, 6 May 2010 16:36:14 +0200, Michael Wild wrote:
>> Looking at the manpage, it seems that CMake will need a Tupfile in
>> every directory that is to contain object files:
>
> Tup would either need to add support for "make install" or CMake wo
On Thu, 6 May 2010 16:36:14 +0200, Michael Wild wrote:
> Looking at the manpage, it seems that CMake will need a Tupfile in
> every directory that is to contain object files:
Tup would either need to add support for "make install" or CMake would
need a different way of doing installs.
Jed
__
On 6. May, 2010, at 14:52 , Jed Brown wrote:
> On Thu, 06 May 2010 08:28:34 -0400, Bill Hoffman
> wrote:
>> The problem with fortran 90, is that you have to find out the depends to
>> figure out the order in which files are built. It has a system where
>> "include like" files are generated
On 6. May, 2010, at 16:15 , Jed Brown wrote:
> On Thu, 06 May 2010 09:10:51 -0400, Bill Hoffman
> wrote:
>> OK, so aside from the fortran depend stuff being moved to generate time.
>> I think the remaining questions are these:
>>
>> How would a large tup system be organized? Would there be a
On Thu, 06 May 2010 09:49:37 -0400, Bill Hoffman
wrote:
> I still don't see the desire for 64 bit when 32 bit works... :)
The 32-bit version either needs to be statically linked, or requires
compatibility libraries. Google Earth and Skype is currently the only
things on my Linux machine that r
On Thu, 06 May 2010 09:10:51 -0400, Bill Hoffman
wrote:
> OK, so aside from the fortran depend stuff being moved to generate time.
> I think the remaining questions are these:
>
> How would a large tup system be organized? Would there be a tup file for
> each target? Would there be one huge t
On Thu, 6 May 2010 08:17:53 -0400, Bill Hoffman said:
>It is not a resource issue. I just don't see the need? What good is a
>64 bit CMake? On Apple someone wanted to a 64 bit CMake, and I had
>them do bench marks, and not noticeable difference could be discerned
>between them.
That was m
On 5/6/2010 9:36 AM, Richard Wackerbarth wrote:
Yes, it works for now. However, the 64-bit version for MacOSX 10.6 is
currently "broken" (at least to the extent that some of the tests
don't "work out of the box" without specific configuration). I think
that it is important that the community have
Yes, it works for now. However, the 64-bit version for MacOSX 10.6 is currently
"broken" (at least to the extent that some of the tests don't "work out of the
box" without specific configuration). I think that it is important that the
community have as much experience as possible with the "new"
On 5/6/2010 9:13 AM, Richard Wackerbarth wrote:
Bill,
As for the need of 64-bit binaries, I agree that it is not a
performance issue.
However, it will be a compatibility issue. Things evolve. Remember
MacOSX 10.0, 10.1? Back then, you could have argued that we didn't need
a new version of CMa
True. Thanks!
Rene
On 5/6/10 7:09 AM, "Marcel Loose" wrote:
> Hi Rene,
>
> -- 8< 8< 8< 8< 8< 8< 8< --
>
>> On the other hand we always want to use or default to XLC or XLF on an
> IBM
>> Power machine and not gcc or gfrotran so I can see our users seeing
> hav
Bill,
As for the need of 64-bit binaries, I agree that it is not a performance issue.
However, it will be a compatibility issue. Things evolve. Remember MacOSX 10.0,
10.1? Back then, you could have argued that we didn't need a new version of
CMake. The binaries from MacOS 9 ran just fine. Now, n
OK, so aside from the fortran depend stuff being moved to generate time.
I think the remaining questions are these:
How would a large tup system be organized? Would there be a tup file for
each target? Would there be one huge tup file for the whole project?
-Bill
__
On Thu, 06 May 2010 08:28:34 -0400, Bill Hoffman
wrote:
> The problem with fortran 90, is that you have to find out the depends to
> figure out the order in which files are built. It has a system where
> "include like" files are generated by the compiler. So, if you have:
>
> a.f90 -> produ
On 5/5/2010 11:42 PM, Zhuang Song wrote:
I tried to run linux binary but always get the following message:
Error running cmake::LoadCache(). Aborting.
Exactly how are you installing the binary?
I simply downloaded the binary files and ran ccmake. Did I miss
anything else before running ccma
On 5/5/2010 9:33 PM, Mike Shal wrote:
Not sure yet, perhaps none of it. It would have to build custom commands
and targets. Basically, support for code generators like
swig/moc/lex/yacc. I guess the auto-depend stuff in tup would work for
C/C++, but the Fortran 90 stuff in CMake would not
On 5/6/2010 4:25 AM, Eric Noulard wrote:
What strikes me as being very strange is that CMake binaries are only
provided as 32-bit executables for Windows and Linux, two of the most
popular platforms where CMake is ever-increasingly used on 64-bit hardware.
Is there any good reason why 64-bit b
Hi Rene,
-- 8< 8< 8< 8< 8< 8< 8< --
> On the other hand we always want to use or default to XLC or XLF on an
IBM
> Power machine and not gcc or gfrotran so I can see our users seeing
having
> to set CC, CXX etc every time as a bit of a pain. Sure they can just
put
>
2010/5/5 Eskandar Ensafi :
> Hello,
>
>
>
> I used to build my own CMake binaries under Linux and Windows, but I got
> tired of having to install compatible versions of third-party libraries such
> as Qt, so I’ve been downloading the prebuilt binaries instead. On the Linux
> side, I gave up on Red
39 matches
Mail list logo
