Reading http://blog.aslakhellesoy.com/tags/jruby/ I get the impression
that the Ruby + Java universe has a *lot* of developers banging on
things. The things banged out may not all be good, but there's a
variety of offerings, and a continuous outpouring of energy and
cross-pollenation. The CMake c
On Dec 18, 2007 12:42 AM, Brandon Van Every <[EMAIL PROTECTED]> wrote:
> Some of those low-end
> things like JRake are even getting traction. There's a constellation
> of blog entries about them. It performs significant work despite not
> having 51 person-years into it.
It occurs to me that Java
On Dec 17, 2007 11:51 PM, Alan W. Irwin <[EMAIL PROTECTED]> wrote:
> On 2007-12-17 23:02-0500 Brandon Van Every wrote:
>
> > I guess you have no fear of a Disruptive Technology biting you in the ass.
>
> That is correct. Disruptive technology by definition is overwhelmingly
> superior,
I'm not su
On Dec 17, 2007 10:35 PM, Alan W. Irwin <[EMAIL PROTECTED]> wrote:
> people and projects are strongly voting with their feet
> despite (and this is an extremely important consideration) virtually
> everybody absolutely hating to change build systems.
Here, I think it's more important to concentrat
On 2007-12-17 23:02-0500 Brandon Van Every wrote:
I guess you have no fear of a Disruptive Technology biting you in the ass.
That is correct. Disruptive technology by definition is overwhelmingly
superior, and I like such technology and don't fear it in the least. Also,
I am comfortable with
On Dec 17, 2007 11:02 PM, Brandon Van Every <[EMAIL PROTECTED]> wrote:
>
> I guess you have no fear of a Disruptive Technology biting you in the ass.
> http://en.wikipedia.org/wiki/Disruptive_technology
> I prefer to keep my eye on the 8-ball.
> http://web.ics.purdue.edu/~ssanty/cgi-bin/eightball.c
On Dec 17, 2007 10:35 PM, Alan W. Irwin <[EMAIL PROTECTED]> wrote:
>
> BUT autotools were first to market in the Linux world so there are still a
> large number of Linux projects that continue with autotools. However, my
> guess based on obvious technical superiority, the possibility of porting to
On Dec 17, 2007 10:32 PM, Brandon Van Every <[EMAIL PROTECTED]> wrote:
>
> The main benefit I see in Groovy, is it paves over all that despicable
> XML syntax.
Here's an example of that.
http://www.javaworld.com/javaworld/jw-10-2004/jw-1004-groovy.html
Cheers,
Brandon Van Every
_
On 2007-12-17 20:30-0500 Brandon Van Every wrote:
When I peruse http://www.ohloh.net/tags/make I notice that most of the
Popular! make-like tools have a particular implementation language
associated with them. If you want a make written in Java, you use
Ant. If you want it in Ruby, you use Rak
I've wondered, how does one script in Java? Same as in the C/C++
universe: with something else. Ergo the JRuby / JRake stuff I just
posted about. Well, some people in the Java universe wanted to
script, and they came up with Groovy. http://groovy.codehaus.org/
They put it on top of Ant and cal
I took a close look to Waf some months ago while searching for the ideal
build tool for the projects I had to port. I used to talk a lot with the
author and found out that the Waf build system isn't superior at all to
other alternatives like CMake. Also, the author just don't care about other
OS th
http://martinfowler.com/bliki/JRake.html
"Now that JRuby is getting more and more mature, several people are
thinking of finally doing something to improve the world of build
scripts by replacing ant with rake.
My former colleague Matt Foemmel has starting doing this for real and
is writing up pr
On Dec 16, 2007 2:55 PM, Brandon Van Every <[EMAIL PROTECTED]> wrote:
> On Dec 16, 2007 1:54 PM, Alexander Neundorf <[EMAIL PROTECTED]> wrote:
> > On Sunday 16 December 2007, Brandon Van Every wrote:
> > >
> > > Meanwhile I just keep expanding my search radius, asking various build
> > > system com
On Dec 16, 2007 1:11 PM, Gonzalo Garramuño <[EMAIL PROTECTED]> wrote:
>
> In summary, thanks. But, no thanks. With all those problems I did not
> even bother checking the speed.
I got a chuckle out of their self-description on
http://www.ohloh.net/tags/build/make , which one might view as a shor
I am generating a project for visual studio with CMake. Is there any way to
turn of c++ exception handling.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
On Dec 17, 2007 3:33 PM, Rodolfo Schulz de Lima <[EMAIL PROTECTED]> wrote:
> Brandon Van Every escreveu:
> > What's so hard about writhing a hash function using only MATH(EXPR
> > ...) ? Geez, once upon a time there were guys who wrote this using
> > punch cards.
>
> I have a life, I live in Copac
On Monday 17 December 2007, Rodolfo Schulz de Lima wrote:
> Alexander Neundorf escreveu:
> > Yes, you can get map-like behaviour by using just variables:
> > SET(MY_MAP_${KEY} myValue)
>
> That's fine if ${KEY} doesn't have spaces nor characters that aren't
> allowed in variable names. As I'm using
Bill Hoffman escreveu:
Something like PCH support is a native build feature that CMake should
support. As such, it should be done in C++, and built into CMake. Some
work has been done to support this. The "hard" stuff for CMake should
be done in C++. That is the implementation language of
On Dec 17, 2007 1:22 PM, Gonzalo Garramuño <[EMAIL PROTECTED]> wrote:
>
> Additional components like cpack or ctest are a plus, but they are not
> a major reason for sticking with cmake.
They aren't *yet*. They certainly could be in the future.
I lost the Chicken Scheme project to a bunch of Lin
Rodolfo Schulz de Lima wrote:
If there is something you can not do with the current cmake language
that could be done in lua (other than aesthetics), let us know, and
provide a patch, or even a report, and most likely we will put it in
CMake. So, no need to fork here...
As I've said somewh
Brandon Van Every escreveu:
What's so hard about writhing a hash function using only MATH(EXPR
...) ? Geez, once upon a time there were guys who wrote this using
punch cards.
I have a life, I live in Copacabana, Rio de Janeiro/Brazil, it's summer,
those stuff, you know :)
Regards,
rod
Alexander Neundorf wrote:
I have my own UnixPaths and modules to work around most of the above,
Can you please post it ?
Sure. It is really two pieces. FindBuildDir.cmake which is called
first and Platforms/UnixPaths.cmake.
FindBuildDir does the hard check of setting up a couple of vari
On Dec 17, 2007 3:00 PM, Rodolfo Schulz de Lima <[EMAIL PROTECTED]> wrote:
> Brandon Van Every escreveu:
> > On Dec 17, 2007 2:29 PM, Rodolfo Schulz de Lima <[EMAIL PROTECTED]> wrote:
> >> A workaround would be
> >> computing a hash from the string and using it as a key, but once again,
> >> it'd b
On Monday 17 December 2007, Brandon Van Every wrote:
> I propose the addition of a BOOL type to the CMake language.
>
> bool(variable [value])
>
> would declare a variable of type BOOL, with an optional value
> supplied. Any SET commands performed on the variable in its scope
> would be subject
David C Thompson wrote:
Gonzalo Garramuño wrote:
Alexander Neundorf wrote:
On Monday 17 December 2007, Gonzalo Garramuño wrote:
Bill Hoffman wrote:
Gonzalo Garramuño wrote:
* good for cross-compilation.
CVS CMake (and the coming 2.6 CMake) have extensive support for cross
compilation.
On Monday 17 December 2007, Brandon Van Every wrote:
> On Dec 17, 2007 2:19 PM, Alan W. Irwin <[EMAIL PROTECTED]> wrote:
> > To supplement Brandon's Boolean wishlist, I would like to see some way to
> > specify a non-default precedence of Boolean operators. Most languages
> > use parentheses for t
Brandon Van Every escreveu:
On Dec 17, 2007 2:29 PM, Rodolfo Schulz de Lima <[EMAIL PROTECTED]> wrote:
A workaround would be
computing a hash from the string and using it as a key, but once again,
it'd be a pain in the *** to do it in cmake script.
I wouldn't shy away from trying it though. I
On Monday 17 December 2007, you wrote:
> Alexander Neundorf wrote:
> > On Monday 17 December 2007, Gonzalo Garramuño wrote:
> >> Bill Hoffman wrote:
> >>> Gonzalo Garramuño wrote:
> * good for cross-compilation.
> >>>
> >>> CVS CMake (and the coming 2.6 CMake) have extensive support for cr
On Dec 17, 2007 2:29 PM, Rodolfo Schulz de Lima <[EMAIL PROTECTED]> wrote:
> A workaround would be
> computing a hash from the string and using it as a key, but once again,
> it'd be a pain in the *** to do it in cmake script.
I wouldn't shy away from trying it though. I wrote a "regex negation
o
On Dec 17, 2007 2:19 PM, Alan W. Irwin <[EMAIL PROTECTED]> wrote:
> To supplement Brandon's Boolean wishlist, I would like to see some way to
> specify a non-default precedence of Boolean operators. Most languages use
> parentheses for this, and ideally that would be true for CMake as well.
>
> Pe
Gonzalo Garramuño wrote:
> Alexander Neundorf wrote:
> > On Monday 17 December 2007, Gonzalo Garramuño wrote:
> >> Bill Hoffman wrote:
> >>> Gonzalo Garramuño wrote:
> * good for cross-compilation.
> >>> CVS CMake (and the coming 2.6 CMake) have extensive support for cross
> >>> compilatio
Alexander Neundorf wrote:
On Monday 17 December 2007, Gonzalo Garramuño wrote:
Bill Hoffman wrote:
Gonzalo Garramuño wrote:
* good for cross-compilation.
CVS CMake (and the coming 2.6 CMake) have extensive support for cross
compilation.
http://www.cmake.org/Wiki/CMake_Cross_Compiling
I'
Alexander Neundorf escreveu:
Yes, you can get map-like behaviour by using just variables:
SET(MY_MAP_${KEY} myValue)
That's fine if ${KEY} doesn't have spaces nor characters that aren't
allowed in variable names. As I'm using a string containing compiler
flags and stuff, this solution isn't
Alexander Neundorf escreveu:
I don't think so.
"analyzing the CMakeLists.txt" means executing them basically completely.
See the following pseudocode:
if(WIN32)
define some args
else
define some other args
endif
You're right, I didn't give it much thought it deserves.
Oh, I think some cm
To supplement Brandon's Boolean wishlist, I would like to see some way to
specify a non-default precedence of Boolean operators. Most languages use
parentheses for this, and ideally that would be true for CMake as well.
Then a test of Boolean inequality of A and B would be
IF((A AND NOT B) OR (N
On Monday 17 December 2007, Gonzalo Garramuño wrote:
> Bill Hoffman wrote:
> > Gonzalo Garramuño wrote:
> >> * good for cross-compilation.
> >
> > CVS CMake (and the coming 2.6 CMake) have extensive support for cross
> > compilation.
> >
> > http://www.cmake.org/Wiki/CMake_Cross_Compiling
>
> I
Bill Hoffman wrote:
It is harder than you think, but maybe you are right. If you look at
Ohloh: http://www.ohloh.net/projects/3238?p=CMake
It shows CMake as a 51 person year project at a cost of 2.7 million.
That may not actually be far from the mark...
Well, following the same standard,
Gonzalo Garramuño wrote:
Bill Hoffman wrote:
Gonzalo Garramuño wrote:
* good for cross-compilation.
CVS CMake (and the coming 2.6 CMake) have extensive support for cross
compilation.
http://www.cmake.org/Wiki/CMake_Cross_Compiling
I'm still having a lot of problems with it. Even cr
On Monday 17 December 2007, Rodolfo Schulz de Lima wrote:
> Bill Hoffman escreveu:
> > Command line options have been a feature request for some time. If
> > someone comes up with a good way to do them, I have no problem putting
> > them in CMake. I guess the problem has always been the iterative
Bill Hoffman wrote:
Gonzalo Garramuño wrote:
* good for cross-compilation.
CVS CMake (and the coming 2.6 CMake) have extensive support for cross
compilation.
http://www.cmake.org/Wiki/CMake_Cross_Compiling
I'm still having a lot of problems with it. Even cross-compiling on a
64-bit
Bill Hoffman escreveu:
CVS CMake (and the coming 2.6 CMake) have extensive support for cross
compilation.
http://www.cmake.org/Wiki/CMake_Cross_Compiling
And I'm using it every day with success. I think there should be some
common toolchain files, for instance, to compile to mingw32 target,
Bill Hoffman escreveu:
Command line options have been a feature request for some time. If
someone comes up with a good way to do them, I have no problem putting
them in CMake. I guess the problem has always been the iterative nature
of the CMakeCache.txt file. --help has to basically run t
Gonzalo Garramuño wrote:
* good for cross-compilation.
CVS CMake (and the coming 2.6 CMake) have extensive support for cross
compilation.
http://www.cmake.org/Wiki/CMake_Cross_Compiling
-Bill
___
CMake mailing list
CMake@cmake.org
http://www.
On 2007-12-17 14:55+0530 Surya Kiran Gullapalli wrote:
Hello all,
I'm a newbie to Cmake and I'm having trouble in FIND_FILE.
I'm using FIND_FILE in a loop like this.
SET (${THIS_FILE} INTERNAL "Temporary Variable" FORCE)
# I Tried this one also
# SET (THIS_FILE INTERNAL "Temporary variable" FO
Rodolfo Schulz de Lima wrote:
Gonzalo Garramuño escreveu:
I honestly don't think it will take 10 more years for a tool to match
the benefits of cmake with a better syntax. As I have said before, I
think it is only 3 or so years away from happening.
It is harder than you think, but maybe you
Rodolfo Schulz de Lima wrote:
So, apart of forking, a build system that wants to be better than cmake
should reimplement 90% of cmake's features, just to add those 10% missing?
Kind of. Not really 90%, but more like 60-70%. It would first have to:
* gotten dependencies correct (thi
Alexander Neundorf escreveu:
If you can find some spare time, there is a command argument parser in
CMake/Source/kwsys/, which is used e.g. by cpack, but not (yet) by cmake.
Using this in cmake is the first step in getting better support for custom
command line parameters. A patch would be very
On Monday 17 December 2007, Surya Kiran Gullapalli wrote:
> Hello all,
> I'm a newbie to Cmake and I'm having trouble in FIND_FILE.
>
> I'm using FIND_FILE in a loop like this.
>
> SET (${THIS_FILE} INTERNAL "Temporary Variable" FORCE)
> # I Tried this one also
> # SET (THIS_FILE INTERNAL "Temporar
On Monday 17 December 2007, Rodolfo Schulz de Lima wrote:
> Gonzalo Garramuño escreveu:
> > I honestly don't think it will take 10 more years for a tool to match
> > the benefits of cmake with a better syntax. As I have said before, I
> > think it is only 3 or so years away from happening.
>
> Wha
First of all, thanks for the relatively quick commit of this feature to
cmake-cvs!
Brad King escreveu:
Thanks, we're looking at the patch. We typically have constructed the
set of source files for a target in a variable so they can be used later:
SET(mylib_SOURCES
mylib1.c
mylib2.c
)
AD
Gonzalo Garramuño escreveu:
I honestly don't think it will take 10 more years for a tool to match
the benefits of cmake with a better syntax. As I have said before, I
think it is only 3 or so years away from happening.
What bugs me is the fact that cmake achieves like 90% of build system
fe
Brandon Van Every wrote:
On Dec 17, 2007 5:46 AM, Gonzalo Garramuño <[EMAIL PROTECTED]> wrote:
premake3/4 is tiny and its syntax is *really* nice.
... Show me a tool that does something CMake
*can't* do, or does badly. ...
Well, in the quote that you did not keep, I posted that premake *is*
Josef,
Here's what I do. The fooCLP.h file is generated by a custom command.
# mark the .clp file as a header file
SET_SOURCE_FILES_PROPERTIES(${CMAKE_CURRENT_BINARY_DIR}/${TMP_FILENAME}CLP.h
PROPERTIES HEADER_FILE_ONLY TRUE)
SET_SOURCE_FILES_PROPERTIES(${TMP_FILENAME}.cxx PROPERTIES
On Dec 17, 2007 9:17 AM, Brandon Van Every <[EMAIL PROTECTED]> wrote:
> Equality
> comparison would be by boolean class, not the specific boolean value.
> The following code succeeds:
>
> set(bool_var ON)
> [...]
> if(bool_var EQUAL Yes)
> # this code is executed
That's not the best exam
So, I've created a new target to generate the header, and made the
library target depend upon it. How do I now make sure that the
generated header is considered in the dependency checks for the objects
build from the CPP files that #include it?
Joe
From: David Cole [mailto:[EMAIL PROTECTED
I propose the addition of a BOOL type to the CMake language.
bool(variable [value])
would declare a variable of type BOOL, with an optional value
supplied. Any SET commands performed on the variable in its scope
would be subject to boolean type constraint. A BOOL can take on the
following val
On Dec 17, 2007 5:46 AM, Gonzalo Garramuño <[EMAIL PROTECTED]> wrote:
>
> premake3/4 is tiny and its syntax is *really* nice.
>
> What's better than cmake (imho):
> - Tiny (only a couple of secs to compile it from source).
> - Written in C (more easily ported than cmake).
>
> What's
Brandon Van Every escreveu:
CMAKE_*_LIBRARY_POSTFIX could serve the purpose of "_d" and so forth.
This is parallel with the meaning of _POSTFIX in the docs.
I didn't know about _POSTFIX. The documentation says that it is
used for all targets, including libraries, isn't it? So
CMAKE_*_LIBRARY
On Dec 16, 2007 10:04 PM, Rodolfo Lima <[EMAIL PROTECTED]> wrote:
> I've been playing around with bug #5997 and I've found out the problem,
> which lies in the fact that when the user sees the variable
> CMAKE_(STATIC|SHARED|IMPORT)_LIBRARY_SUFFIX, he assumes that this is
> something to be added to
Hi,
I am using CPack with DEB generator. My install dir is in
/work/install/Project and I have a usr and a etc dir installed.
But the debian package generated by CPack inserts a usr directory so I get
my usr in usr/usr and my etc in /usr/etc.
I don't manage to understand why and where is inserted t
Filipe Sousa wrote:
For those who love lua and want a build system there is premake
http://industriousone.com/premake
And I know that there is another build system that uses lua but I can't
find the link.
premake3/4 is tiny and its syntax is *really* nice.
What's similar to cmake:
-
> -Original Message-
> From: Bill Hoffman [mailto:[EMAIL PROTECTED]
> Sent: 14 December 2007 14:16
> To: Josef Karthauser
> Cc: cmake@cmake.org
> Subject: Re: [CMake] PRE_BUILD custom commands don't appear to be
> working
>
> Josef Karthauser wrote:
> > I don't suppose anyone had any t
Hello all,
I'm a newbie to Cmake and I'm having trouble in FIND_FILE.
I'm using FIND_FILE in a loop like this.
SET (${THIS_FILE} INTERNAL "Temporary Variable" FORCE)
# I Tried this one also
# SET (THIS_FILE INTERNAL "Temporary variable" FORCE). But this one
threw errors.
FOREACH (ofile ${FILES})
I'm going to try that today.
From: David Cole [mailto:[EMAIL PROTECTED]
Sent: 14 December 2007 18:18
To: Bill Hoffman
Cc: Josef Karthauser; cmake@cmake.org
Subject: Re: [CMake] PRE_BUILD custom commands don't appear to be
working
But you should be able to put your custom command in its
64 matches
Mail list logo
