king on the "problem" machine, or
investigate why CMake (any CMake) doesn't work on the "problem"
machine.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
as simple as the level of complication of your
build. If I want encapsulation, I write a macro. Otherwise I'll just
write straight CMake script, because I'd rather read CMake script than
the docs of 5 different Unixy tools that all do their own kind of
regular expression processing.
Cheer
statement
> > is still TRUE.
>
> It is checking to see if the VARIABLE has a value at all. It is old
> code before we had IF(DEFINED VARIABLE) but works with all versions of
> CMake.
One of these days I'm going to try to construct a pathological input
to make it barf. But I
ow to solve this one.
Through hacking, one finds the bleeding edge of CMake. When I've
found the bleeding edge, I try to obtain 1 of 2 results:
- an approach that works. If it's hairy, I may file a feature request.
- a bug that's reproducible. In which case, I file a bug report.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
that (c)cmake --help is under-documented
on this point.
Cheers,
Brandon Van Every
On Dec 12, 2007 8:08 PM, Jesse Corrington <[EMAIL PROTECTED]> wrote:
> When running CMake from the command line, how can I specify the directory to
> put the output files in. Thanks.
>
> Jesse
>
> _
e an
abnormal result. There were bugs regarding CMake script return codes
once upon a time; hope those were fixed.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
uch easier to replace when migrating
build systems. Sure, CMake has this "call out to whatever you like"
philosophy. But I think builds are more maintainable and portable
when CMake gets rid of all those tools. I also think it's
strategically better for CMake's growth, to ha
bug or fix it.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
had incorrect arguments: ${CMAKE_CXX_FLAGS} STREQUAL " " (Unknown arguments s
pecified).
Called from: [1] C:/devel/moz/flags.cmake
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
#x27;t think
that's quite enough to make the switch. What I'd really like to see,
is an example of a build system that's much better in a "fullblown"
language like Lua, that would be extremely painful to write in a
stripped down language like CMake. We'll have to ask other build
communities about such a project; obviously it won't exist in CMake
code.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
take their issues seriously. I will remind:
far more people don't use CMake, than do. Having to learn Yet Another
Scripting Language is one of the perceived barriers. So addressing
the issue, or *appearing* to address the issue, is strategically
important.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
people examine other
build systems and return with tangibles, i.e. "this is clearly better"
rather than "I think it would be better."
I agree that Kitware hasn't been persuaded of the value of using a 3rd
party open source la
may gain plenty of mindshare as a build tool. But CMake script will
never do so. It is incapable of that. It is not recognized by the
computer industry as an important development language, and it never
will be.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
think
overhauling the string-oriented variables to make them list-oriented
is feasible. And in one's own code, one has to choose whether to
embrace a string-oriented or list-oriented flag handling style. More
grist for the chapter.
Cheers,
Brandon Van Every
," I'd call that a documentation problem.
CMake script users shouldn't have to look under the hood to figure out
how use CMake modules either.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
On Dec 14, 2007 4:55 PM, Rodolfo Schulz de Lima <[EMAIL PROTECTED]> wrote:
> Brandon Van Every escreveu:
>
> > I'm not willing to concede the clarity. As I just wrote, "backwards
> > compatibility" is an issue to solve, not a dealbreaker. As for labor,
As long as I adopt a convention for what's a list
and what's a string. And as long as I don't care about semicolons ;
in my list elements.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
On Dec 14, 2007 8:45 PM, Alexander Neundorf <[EMAIL PROTECTED]> wrote:
> On Friday 14 December 2007, Brandon Van Every wrote:
> > On Dec 14, 2007 2:38 PM, Bill Hoffman <[EMAIL PROTECTED]> wrote:
> > > It really boils down to this: There is no way we can ever sto
On Dec 14, 2007 10:57 PM, Rodolfo Lima <[EMAIL PROTECTED]> wrote:
> Brandon Van Every escreveu:
>
> > Most of my concerns about nicety of
> > language are strategic, not tactical.
>
> Let's not forget that cmake is being used by KDE, I think they wouldn't
know where they went, and what competing products they're
working on.
> and are just happy to have the software build
> correctly the first time they build it. (I could have fixed at least
> one but instead of writing this email :) ).
Short-term vs. long-term gain is
On Dec 15, 2007 1:55 PM, Brandon Van Every <[EMAIL PROTECTED]> wrote:
> On Dec 15, 2007 12:41 PM, Bill Hoffman <[EMAIL PROTECTED]> wrote:
> >
> > There are some vocal
> > complainers about the language, but I suspect there is a silent majority
> > that
aintaining significant new CMake
functionality.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
t type var = var - 1. The problem with assuming that "0"
means FALSE, is it assumes I got my "0" by counting with a MATH
expression. What if I got my "0" by matching with a regex, like a
digit of a library version?
"-NOTFOUND" doesn't trouble me so much, a
On Dec 16, 2007 11:57 AM, David Cole <[EMAIL PROTECTED]> wrote:
> On 12/16/07, Brandon Van Every <[EMAIL PROTECTED]> wrote:
>
> > What's so great about "n" and "no" ?
>
> Nobody has claimed that they are great...
>
>
> &g
On Dec 16, 2007 1:11 PM, Gonzalo Garramuño <[EMAIL PROTECTED]> wrote:
> Brandon Van Every wrote:
> > Waf is the offering of a fellow
> > who clearly thinks OO is important in a build system for some reason.
> > http://code.google.com/p/waf/
> >
>
> A quick ev
On Dec 16, 2007 1:44 PM, Alexander Neundorf <[EMAIL PROTECTED]> wrote:
> On Sunday 16 December 2007, Brandon Van Every wrote:
> > On Dec 16, 2007 11:57 AM, David Cole <[EMAIL PROTECTED]> wrote:
> > > On 12/16/07, 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:
> > On Dec 16, 2007 1:11 PM, Gonzalo Garramuño <[EMAIL PROTECTED]> wrote:
> > > Brandon Van Every wrote:
> > > > Waf is
currently means. CMAKE_*_LIBRARY_EXTENSION could be a
documented synonym for it. CMAKE_*_LIBRARY_SUFFIX could be moved to
the depreciated section of the docs, but its behavior would remain
unaltered.
CMAKE_*_LIBRARY_POSTFIX could serve the purpose of "_d" a
o, or does badly. That's what I'm looking for when I ask
"the OO question." Things that CMake can't do are potential strategic
threats. Nicer syntax is not.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
atched in typical string processing. "0" is problematic, as it is a
single character like "n". A similar proposal for a NUMBER data type,
and CMAKE_REQUIRE_NUMBER, could be used to eliminate the problem of
the "0".
Cheers,
Brandon Van Every
___
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
mmers, it would
make migrations from Autoconf easier. I had to write a substantial
body of code to do it. If the feature were present, translation would
be much more 1:1 and easier to implement.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cm
uot; hash as a
prototypical basis for a more official CMake capability someday. In
my case, because I wrote the "regex negation operator" and other
string handling extensions, I have a pretty good idea what a
PCRE-based regex interface should look like.
Cheers,
Brandon Van Every
___
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
he best solution to that problem.
Otherwise, you give them a great build system, and they'll balk the
minute they have to lift a finger to maintain it.
Cheers,
Brandon Van Every
___
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 car
ol wars, we'll be seeing shelfs full of books at Barnes & Noble and
tons of jobs listing it as a "must have" skill. I wonder where Waf
thinks it is, relative to all of that. Happy with the $0 "we really
don't have to bother with Windows" open source market?
Cheers,
B
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 ra
l quality build tools, because there simply
aren't enough Ruby programmers who need to compile something. So the
use of Ruby to solve build problems, will depend upon Ruby living
symbiotically with other languages that do need to be compiled (C/C++,
Java, C#).
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
mming?
The Java universe has a lot of JVM-based scripting languages. I'm
trying to figure out whether any are more popular than the others.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
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
Cheer
n
> technical improvements that don't disturb things too much and which make
> CMake build systems simply easier to design and maintain.
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 e
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.purdu
. It's important to look at competitors and determine what
engineers think is attractive in a build tool.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
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 overwhelmin
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
ime. So Ant got very popular
and is terribly pervasive. Now there's a movement that thinks XML
wasn't such a hot idea, that you really do need scripting in a build
system after all, and that it's advantageous to get rid of the XML.
This notion seems to have gained s
On Dec 18, 2007 2:21 AM, Brandon Van Every <[EMAIL PROTECTED]> wrote:
> Reading http://blog.aslakhellesoy.com/tags/jruby/ I get the impression
> that the Ruby + Java universe has a *lot* of developers banging on
> things.
>
> Maybe it wouldn't all be good! :-) Mayb
t the "deadline" for PCREs to
> be included in CMake 2.6.0 would be, nothing.
Dunno there. I'm not seeing any downside to PCRE, so long as it's
disambiguated from CMake's current regexes.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
SF
couldn't get GNU/Hurd done, so GNU/Linux took over. "Screw Windows"
is all very fine and well, but if the pace of your R&D is glacial, the
rest of the open source industry isn't going to sit around waiting for
your Windows-killing software.
Cheers,
Brandon Van Every
n if that breaks something.
It should be clearly documented as having that purpose.
Heh, I wonder if in some instances the opposite would be needed,
include(Ancient) ! :-) Something that either suppresses appeals to
modernity, or warns vehemently against them.
Cheers,
Brandon Van Every
es do. Once encapsulated, I'd be free to
set_properties(GLOBAL PROPERTIES REQUIRE_BOOL TRUE) and get rid of the
string pollution. I'm happy, the backwards compatible crowd is happy.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
ll uses
> of command line arguments will be the most trivial one, i.e., statically
> define those arguments, so sticking with like 90% of all use cases would
> be good enough, IMHO.
Exactly. "Anything could happen" is a lot of fretting about nothing.
Cheers,
Brandon Van Every
_
On Dec 18, 2007 1:06 PM, James Bigler <[EMAIL PROTECTED]> wrote:
> Brandon Van Every wrote:
> >
> > include(Modern) would turn on improvements that are
> > clearly desirable but break backwards compatibility.
> >
> > Heh, I wonder if in some instances th
s has anything to do with it.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
On Dec 18, 2007 1:44 PM, Rodolfo Schulz de Lima <[EMAIL PROTECTED]> wrote:
> Brandon Van Every wrote:
>
> > How about include(ForwardsCompatibility). That would make the intent
> > really clear.
>
> IMHO a better solution would be to specify which CMAKE vers
On Dec 18, 2007 1:55 PM, Rodolfo Schulz de Lima <[EMAIL PROTECTED]> wrote:
> Brandon Van Every wrote:
>
> > I thought REMOVE_RECURSE was a straightforward unconditional nuke. I
> > don't see that cleanliness has anything to do with it.
>
> Well, if I want to cle
On Dec 18, 2007 2:36 PM, Rodolfo Schulz de Lima <[EMAIL PROTECTED]> wrote:
> Brandon Van Every wrote:
>
> >> Hint: there's already the
> >> cmake_minimum_required command (at least in cmake-cvs, that is)...
> >
> > cmake_minimum_required has been ar
king about resides. This is created by
> cmake during build configuration, but IMHO it should be
> FILE(REMOVE_RECURSE ...) so that 'make clean' removes any directories
> specified with CMAKE_ADDITIONAL_CLEAN_FILES property.
Sounds like a bug. File a
e has to
actually lead on any given feature. This is why projects often use a
bug tracker to organize this kind of stuff. The problem with a bug
tracker is it doesn't tell you at-a-glance what people are working on.
What we really need is a way to dump that information o
scripts don't do that. One could do it for new scripts, but
old scripts are what they are. Also, I don't necessarily want my
script to be limited to CMake's behavior when I wrote it.
Cheers,
Brandon Van Every
___
CMake mailing list
C
On Dec 18, 2007 6:43 PM, Rodolfo Lima <[EMAIL PROTECTED]> wrote:
> Brandon Van Every escreveu:
>
> > But old scripts don't do that. One could do it for new scripts, but
> > old scripts are what they are. Also, I don't necessarily want my
> > script to be
On Dec 18, 2007 7:31 PM, Rodolfo Lima <[EMAIL PROTECTED]> wrote:
> Brandon Van Every escreveu:
> >> That would be easy to cope with, no version specification = 2.4.7.
> >
> > If it actually works under 2.4.7 and doesn't need some other earlier
> > versi
buggy behaviour in the code would
> have to stay in an if(version==2.4.7) block, and next to it the fixed block
> for newer versions. This is not maintainable.
The maintainability would depend on the codebase. In some cases it
would be easy, in others hard or
have different behavior.
Users don't know any better so they do stuff with SUBDIRS. CMake
2.6.0 will list SUBDIRS in the depreciated section of the
documentation.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
rary_objects_twice.2C_once_for_shared_and_once_for_static.3F.21__I_don.27t_like_that.21
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
On Dec 19, 2007 10:47 AM, Joël Schaerer <[EMAIL PROTECTED]> wrote:
> I have read this FAQ entry, but it doesn't seem to adress my issue at all...
Did you read http://www.cmake.org/Bug/view.php?id=5155 ?
Cheers,
Brandon Van Every
___
CMak
On Dec 18, 2007 8:32 PM, Rodolfo Lima <[EMAIL PROTECTED]> wrote:
> Brandon Van Every escreveu:
>
> >> We would have to guarantee that version 2.4.7 executes correctly every
> >> script made up till now.
> >
> > I don't see how we could.
>
>
On Dec 19, 2007 1:52 AM, Gonzalo Garramuño <[EMAIL PROTECTED]> wrote:
>
> Sure, lua runs 10 times faster than the cmake language does, but that's
> a different story.
So what's the story? Can you substantiate that?
Cheers,
Brandon Van Every
me ago. You want people coming from the Autoconf
world to get enough of a warm squishy feeling that they stick with
CMake. Over time they learn how to use CMake properly, using
CMakeSetup / CCMake, and forget their command line ways.
Cheers,
Brandon Van Every
On Dec 18, 2007 9:50 PM, Rodolfo Lima <[EMAIL PROTECTED]> wrote:
> Is there a way to call a dynamically created macro name?
You could use a macro to generate a CMake script containing a macro,
and then call that script. :-)
Cheers,
Brandon
e of this.
I'd be happy to see your comments on this in the bug report. It's not
going to get action unless someone other than myself lights a match
under the issue.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
htt
static library. I came up
with a hack to find CMake's objects and reuse them, so that the user
of a static library would not have to add additional link flags. In
particular, I wanted the user to be able to specify -lchicken, and not
have to specify -lchicken -lpcre.
Cheer
sure argue a lot about an easy feature to
implement. Where's the harm in making it easy for the user to find
the object files?
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
I didn't want the end
user to be aware of PCRE, it was an implementation detail of Chicken
that they should never have to think about.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
On Dec 19, 2007 4:24 PM, David Cole <[EMAIL PROTECTED]> wrote:
> On 12/19/07, Brandon Van Every <[EMAIL PROTECTED]> wrote:
> > ...an easy feature to
> > implement...
>
> So easy to implement that the attached patch was 0 bytes...?
Bill's comments at http://ww
will have include(Modern), then include(Moderner),
> then include(Modernerst), then include(ÜberModern),...
Its contents would have to be managed according to some policy or
mission statement. This is no different than deciding what's a bug,
what's a feature, what to put in a new version of CMake, what to leave
out.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
On Dec 19, 2007 12:47 PM, Rodolfo Schulz de Lima <[EMAIL PROTECTED]> wrote:
> Brandon Van Every escreveu:
>
> > You could use a macro to generate a CMake script containing a macro,
> > and then call that script. :-)
>
> Nice... :)
In fact, it turns out you can u
hat you're going to do
anything there. It could just be an intermediate part of your source
tree. Perhaps the CMakeLists.txt in that subdirectory merely contains
more ADD_SUBDIRECTORY commands.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cm
On Dec 19, 2007 6:04 PM, Brandon Van Every <[EMAIL PROTECTED]> wrote:
> On Dec 19, 2007 12:47 PM, Rodolfo Schulz de Lima <[EMAIL PROTECTED]> wrote:
> > Brandon Van Every escreveu:
> >
> > > You could use a macro to generate a CMake script containing a ma
an I keep going with it? If
not, at least it'll teach me what regexes can't do, computationally
speaking. But who knows, maybe anything that has PCRE could turn into
a metaprogramming language translator. It would be really slick from
a portability and maintenance standpoint.
On Dec 19, 2007 7:32 PM, David Cole <[EMAIL PROTECTED]> wrote:
> Where are these 10 lines?
In the bug tracker, conspiciously above Bill's comments. They've been
there for 6 months.
http://www.cmake.org/Bug/view.php?id=5155
> On 12/19/07, Brandon Van Every < [EMAIL PROT
been "the boring
stuff that runs slowly."
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
ot some source code for sample projects,
but you don't want the sample projects built by default. Test cases
are another example.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
l
regexes, but you can still get pretty far, and PCRE is coming.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
If we want CMake included in the path, whatever path we
chose, we check a box. Do people not do this sort of thing on Macs?
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
sing ADD_CUSTOM_COMMAND COMMAND ${CMAKE_COMMAND} -P
myscript . Of course, this isn't going to configure anything. :-)
Are you just trying to perform text substitutions or something?
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
ompile and
try_run instead of just doing execute_process.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
On Dec 22, 2007 4:24 PM, Bill Hoffman <[EMAIL PROTECTED]> wrote:
> I still don't see the reason for the strong resistance to using an
> installer program. Many Apple products including Xcode use one.
Clearly a cultural issue. You're running afoul of "Mac native"
culture as opposed to cross-platf
; you weren't using svn and trying to sell it to you :)
>
> Before you switch to svn please use git. It's much better than the pain of cvs
> or svn.
Mozilla is migrating to Mercurial. They rejected git; I forget why.
It's early days for peer-to-peer source control, but based
On Dec 22, 2007 6:20 PM, Brandon Van Every <[EMAIL PROTECTED]> wrote:
>
> In that world view, you'd add "first run invokes path configuration"
> because it gives native MacOS bigots a warm squishy feeling. Then
> they're singing the praises of CMake inst
build system communities. What's a major project
in SCons or some other build system that would be really clunky to do
in CMake?
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
e who do not understand
> path issues probably don't care what is placed where, they just want
> their app to work as Bill has stated.
If checkboxes to set / not set the path are too complicated, then the
installer can issue a warning message that the user ne
mas! And all those other holidays if
anyone wants to throw them in there. :-)
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
ot; with respect to build systems, has yet
to be proven. Until someone proves it, with a concrete example,
Kitware will never be convinced that any "better" language is needed.
So I'm saying, quit talking about how Lua or some other language is
supposed to be better,
t; Sounds like a low priority feature request to
me. File it in the bug tracker.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
On Dec 28, 2007 1:33 PM, Rodolfo Lima <[EMAIL PROTECTED]> wrote:
> Brandon Van Every escreveu:
>
> > "Too" cumbersome? Surely you jest. What's a long-winded list of
> > patterns in terms of your development time? Two minutes tops?
>
> Oh well... t
e you using? CMake 2.4.7 documentation says
plenty about this. INCLUDE(DIRECTORY ... PATTERN blah ...) should
work fine without an EXCLUDE
>and I've already tried without success.
If you're using CMake 2.4.7 and can reproduce that with a sim
On Dec 28, 2007 4:38 PM, Brandon Van Every <[EMAIL PROTECTED]> wrote:
> On Dec 28, 2007 2:51 PM, Rodolfo Lima <[EMAIL PROTECTED]> wrote:
> > David Cole escreveu:
> > > Can't you use "PATTERN" without the "EXCLUDE" to achieve this?
> >
&
se "src" instead of "src/" ?
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
201 - 300 of 663 matches
Mail list logo
