n't have a clue about it,
> and admitted it a few days ago if I recall. Do I need to send an
> email to Google to "make you stop"? (<- joke).
Below is the kind of missive that led me to ask Sebastian to stop
sending me private e-mails. I tolerated his diatri
On Tue, Mar 4, 2008 at 12:39 PM, Sebastien BARRE
<[EMAIL PROTECTED]> wrote:
>
> We are actually reworking a few of our websites at Kitware (see
> http://cdash.org/), maybe CMake is on the list.
That's a decently handsome webpage. If only the wiki could be skinned.
Cheer
ently think is warranted. What wiki improvement would cause
Kitware to see it as a profit center?
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
On Tue, Mar 4, 2008 at 1:29 PM, Sebastien BARRE
<[EMAIL PROTECTED]> wrote:
> At 3/4/2008 12:28 PM, Brandon Van Every wrote:
> > > >
> > > > - CMake script must be maintained indefinitely for a small percentage
> > > > of users no matter what the m
At the macroeconomic scale, CMake script is too
parochial and not what the marketplace wants as The One True Build
Language. In fact the marketplace may not want The One True Build
Language at all; they might be amenable to the one true build engine.
Someone like Sun could dump money into making a lot o
On Tue, Mar 4, 2008 at 2:30 AM, Jesper Eskilson <[EMAIL PROTECTED]> wrote:
>
> Brandon Van Every wrote:
> > On Mon, Mar 3, 2008 at 6:06 PM, Brandon Van Every <[EMAIL PROTECTED]>
> wrote:
> >> >
> >> > >
> http://www.nabble
On Mon, Mar 3, 2008 at 6:13 PM, James Mansion
<[EMAIL PROTECTED]> wrote:
> Brandon Van Every wrote:
> >> Then probably that is because those projects use Ruby AND Python AND Tcl
> >> - so I have to have them anyway. Hey, lets all use C89. Everyone has
> >>
On Mon, Mar 3, 2008 at 6:06 PM, Brandon Van Every <[EMAIL PROTECTED]> wrote:
> >
> > >
> http://www.nabble.com/SCons-Future-Directions-and-Thoughts-td15176258.html
> >
> you can learn tons about SCons from that thread.
And there's one *really* spectacu
On Mon, Mar 3, 2008 at 3:07 PM, Brandon Van Every <[EMAIL PROTECTED]> wrote:
> On Mon, Mar 3, 2008 at 2:11 PM, Brandon Van Every <[EMAIL PROTECTED]> wrote:
> > VMWare is a large commercial project.
>
> > http://www.nabble.com/SCons-Future-Directions-and-Th
e to drop it and use something else, like (don't get me started
> on the wrong tail)
The archives contain abundant ink on this subject. Well, bytes, whatever.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
n techie marketing. So grudgingly, I'll see if I can stand to
learn some NVU. http://www.nvu.com/ I had a website a long time ago
that I used FrontPage 2000 for. That was no fun, and it never
amounted to anything resembling professional production values.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
On Mon, Mar 3, 2008 at 2:11 PM, Brandon Van Every <[EMAIL PROTECTED]> wrote:
> VMWare is a large commercial project.
> http://www.nabble.com/SCons-Future-Directions-and-Thoughts-td15176258.html
My impression so far is that SCons appeals to a company that wants to
program a cust
jects large enough to say anything. I
don't think there are any competing proprietary tools? If I've
overlooked something please let me know.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
for anyone's specific purposes though. The code is available under
Mozilla's usual tri-license.
https://bugzilla.mozilla.org/show_bug.cgi?id=416982
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
one who only does periodic maintenance and
doesn't try to be a CMake expert.
Maybe we could just ask our program text editor to magically insert an
appropriate comment, based on the if(clause). It would be a form of
pretty printing. It would comment any conditionals that are m
rd C FFI. Well, TIOBE would seem to
say that Common Lisp is more popular than Lua, so indeed maybe old
prejudices are fading.
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
> P.S. BTW, rake is something like a 200 line script only, so it is
> extremely bare-bones.
Hm. A reputation disproportionate to its size. How does a language
or tool manage that? Early niches filled?
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
On Sun, Mar 2, 2008 at 9:22 PM, Brandon Van Every <[EMAIL PROTECTED]> wrote:
> On Sun, Mar 2, 2008 at 7:29 PM, Brandon Van Every <[EMAIL PROTECTED]> wrote:
>
> > http://incubator.apache.org/buildr/
>
> A review of Buildr
> http://danielroop.com/blog/2007/08/
On Sun, Mar 2, 2008 at 7:29 PM, Brandon Van Every <[EMAIL PROTECTED]> wrote:
> http://incubator.apache.org/buildr/
A review of Buildr
http://danielroop.com/blog/2007/08/25/buildr-review/#more-50
Says that Buildr is implementing a DSL for builds, it's not straight
Ruby. Also,
On Sun, Mar 2, 2008 at 7:46 PM, Brandon Van Every <[EMAIL PROTECTED]> wrote:
> On Sun, Mar 2, 2008 at 7:29 PM, Brandon Van Every <[EMAIL PROTECTED]> wrote:
> >
> >
> http://www.onjava.com/pub/a/onjava/2007/12/05/introducing-raven-an-elegant-build-for-java.html
&g
On Sun, Mar 2, 2008 at 7:29 PM, Brandon Van Every <[EMAIL PROTECTED]> wrote:
>
>
> http://www.onjava.com/pub/a/onjava/2007/12/05/introducing-raven-an-elegant-build-for-java.html
The comments following this article are interesting. For instance, on syntax:
"This is just stu
solve Java build problems, with different
approaches than Raven.
http://antwrap.rubyforge.org/
http://incubator.apache.org/buildr/
I intend to find out if any of these tools have been used for large
projects, and if they exist, whether Ruby has demonstrated any
remarkable advantages.
Cheers,
B
ould like to see a large scale project that proves
that, rather than assuming it.
From a marketing and documentation standpoint, standard scripting
languages are provably better than DSLs.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
issues may not go away.
They may have to be handled by marketing and political means. That's
an avenue that the CMake community has put very little effort into.
I'm not going to point fingers, as I precipitated the cmake-promote
mailing list once upon a time and have done very little since then.
Too busy coding like most programmers are. I'm just trying to make a
pitch for humanistic rather than technical solutions to some of these
problems. Techies tend to overlook anything that isn't tech.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
On Sat, Mar 1, 2008 at 7:08 PM, Brandon Van Every <[EMAIL PROTECTED]> wrote:
> Especially in open source, I think it is
> reasonable to make developers do trivial amounts of work to move on,
> at some point, if the migration tools have been thoroughly tested and
> prove
support 2 languages indefinitely. I
just see it as unnecessary. Especially in open source, I think it is
reasonable to make developers do trivial amounts of work to move on,
at some point, if the migration tools have been thoroughly tested and
proven in the field.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
M_TARGET(test COMMAND echo "A=\${A}")
> | INSTALL(CODE "MESSAGE(\"A=\${A}\")")
>
> | $ make A=a test
> | A=a
> | $ make A=a install
> | A=
There are definitely string argument evaluation level bugs. I
resorted to passing variables rather tha
you can generally use for any mailing list archive, unless the archive
has been made invisible to non-subscribers.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
t from a marketing standpoint, this makes sense.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
s of marketing prejudice, most
newcomers will hate the repetition. I think that's blind prejudice on
their part and that the repetition has technical merit. But I agree
it doesn't have marketing merit.
> It's unmaintainable because every time you make the slightest modification
who knows better can answer this one. CMake is
definitely not designed around this case use, it's designed around
being part of the build.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
On Fri, Feb 29, 2008 at 12:11 AM, Sebastien BARRE
<[EMAIL PROTECTED]> wrote:
> At 2/29/2008 12:03 AM, Brandon Van Every wrote:
>
> > > You've got a deal. I'll make sure to swing by Bill's office tomorrow
> > > and remind him about his "realizat
On Thu, Feb 28, 2008 at 11:41 PM, Sebastien BARRE
<[EMAIL PROTECTED]> wrote:
> At 2/28/2008 09:06 PM, Brandon Van Every wrote:
>
> > > So, I guess I will wait until then, and you can prove me wrong... Until
> > > then, can you give it a break?
> >
>
On Thu, Feb 28, 2008 at 5:54 PM, Bill Hoffman <[EMAIL PROTECTED]> wrote:
> Brandon Van Every wrote:
>
> >
> >> Just suppose I am correct and it is
> >> not possible to write a good enough translator. Would you then still
> >> advocate droppin
e
> large projects with a translator is not one I would appreciate being
> driven into by the CMake developers.
Estimating conservatively, I got 1/2 of the way there with Mozilla.
Autoconf + GMake --> CMake is a much more difficult translation
problem than CMake --> Lua. I know what
On Thu, Feb 28, 2008 at 9:53 AM, Bill Hoffman <[EMAIL PROTECTED]> wrote:
> Brandon Van Every wrote:
>
> >
> > Only thing problematic I could see, is if someone's getting clever and
> > using CMake script to generate CMake script. I think it would be
> >
On Wed, Feb 27, 2008 at 8:58 PM, Bill Hoffman <[EMAIL PROTECTED]> wrote:
> Brandon Van Every wrote:
>
> > That's 2 cantankerous languages and a rather general problem domain.
> > CMake script is a rather limited language. Not that hard to map it to
> > L
On Wed, Feb 27, 2008 at 5:37 PM, Bill Hoffman <[EMAIL PROTECTED]> wrote:
>
> Brandon Van Every wrote:
> >
> > I think if the automated translation tool had proven itself for a
> > couple of years, it would be perfectly reasonable to force people to
> > mov
X
REPLACE ...) on the output. Sometimes the version of a tool is
contained in a .h file. In that case you'd use try_compile and write
some C preprocessor commands to capture the output.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http
So there is still that 2 year window of supporting 2
languages.
> So, we might have two official languages someday, but no more than that.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Miyagi from "The Karate Kid" said something like, "better to know
1 kick well."
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
ting languages.
I think a migration needs a language translator, so that builds can
be migrated quickly to the new, preferred, standard language. CMake
script --> Lua translation is certainly doable, but someone would have
to do it, and it would be real work.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
ense sucks. The price of Ruby's nice language features is
that it's slow. Anyways, if someone could explain to me why Rake
matters, I'd listen.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
troyed? ;)
Actually, all of the rings lost their power at that time.
Analogously, we'd forget about build systems and go into the West.
We could speculate about who's the Dark Lord. By my demeanor I am
surely an Uruk-hai captain. >-)
Cheers,
Brandon Van Every
_
ved need to do anything imaginable, because they don't actually
know enough about build systems to know what's really required.
Small-to-medium sized projects are a documentation and marketing
problem, not a technical problem.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
ould have no
incentive to contribute features to standard CMake. This is a form of
community fragmentation.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
confirmed this opinion of yours? I did not attend,
but I read the schedule and noticed there were presentations for both
CMake and SCons. Was it something the lecturers said? Audience
questions?
Cheers,
Brandon Van Every
___
CMake mailing li
in the bug tracker as
{document, text} bugs, along with the exact words you think should be
used.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
On Sun, Feb 24, 2008 at 12:56 PM, E. Wing <[EMAIL PROTECTED]> wrote:
> On 2/24/08, Brandon Van Every <[EMAIL PROTECTED]> wrote:
> >
> > So are you going to write this framework for us, that makes all the
> > work of supporting multiple languages magically go aw
x27;t. They can pay for that kind of support.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
ndex.html?tiobe_index
Find me evidence of people who refuse to touch Lua.
Trying to please everyone by technical means will result in marginal
gains in popularity. A marketing campaign would get a lot more bang
for the buck.
Cheers,
Brandon Van Every
___
d to CMake's BSD license.
Most of the languages other than Lua are somewhat bloated, both in
terms of execution size and speed.
In short, I do not see value in trying to be all things to all people.
That's an expensive way to do business.
Cheers,
Brandon Van Every
_
On Thu, Feb 21, 2008 at 6:51 PM, Neal Meyer <[EMAIL PROTECTED]> wrote:
> On windows I need a way to get a drive letter from a path. Does
> anybody have any tricks for doing this?
Not a trick: string(REGEX MATCH ...)
Cheers,
Brand
endif()
What's wrong with:
include(findXXX)
if(XXX_FOUND)
someXXX_macro(whatever)
endif(XXX_FOUND)
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
getting people to write docs, even when people
are paid to write docs (unlike here). Here's a semi-illuminating
article on docbook vs. DITA.
http://norman.walsh.name/2006/03/24/dita2006 If nothing else you
should read it just to understand what docbook thinks it
o they talk about parents. Well when I'm more awake
I'll think about the wordsmithing. I keep wanting to work the word
'call' or 'caller' in somehow. If you're altering the caller's variables,
why not talk about the caller?
Cheers,
Brandon Van Every
_
clunky
feeling to it. Even if it turns out to be practical, CMake script
does have an image problem. Keywords that don't exacerbate it would
be better. I can't quite think of what PARENT_SCOPE really means to
do, if parent directories are taken out of the
On Fri, Feb 15, 2008 at 12:32 PM, Bill Hoffman
<[EMAIL PROTECTED]> wrote:
> Brandon Van Every wrote:
> > On Fri, Feb 15, 2008 at 9:59 AM, Bill Hoffman <[EMAIL PROTECTED]> wrote:
> >> http://www.cmake.org/Wiki/Really_Cool_CMake_Features
> >
> > I think
omutil.h new to CMake
CVS? If so, I bet it won't build with a Windows Server 2003 R2 SDK
and free VC8.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
l-informed soul takes issue with the word in the
sense of, "Oh JOY" (not), the feedback can only stimulate the CMake
community and increase CMake's notoriety.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
specific issue?
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
t.
Guys, guys, read the list and add it yourselves! It's a wiki. We
don't need discussion here.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
on
"public: __thiscall _bstr_t::Data_t::Data_t(char const *)"
([EMAIL PROTECTED]@@[EMAIL PROTECTED]@Z)
CMakeLib.lib
Windows Vista, with the free VC8 compiler, using CMake 2.4.8 as the
build tool, building CMake 2.4.8 works fine.
Cheers,
Brandon Van Every
_
2008/2/13 Malhotra, Anupam <[EMAIL PROTECTED]>:
>
> Please notice that $(IntDir) is automatically changed to "$"(IntDir) in the
> actual post build setup. Can anyone please tell me if this is a bug in
> cmake?
Looks like a bug to me. File it.
does not have any configuration step or cache. However, it's
not reasonable for it to die with the error it's giving. I've filed
bug http://cmake.org/Bug/view.php?id=6337 "cmake -P crashes on
configure_file".
Are you using cmake -P or a CMakeLists.txt?
Cheers,
Brandon V
On Feb 12, 2008 12:34 PM, Alexander Neundorf <[EMAIL PROTECTED]> wrote:
> On Tuesday 12 February 2008, Brandon Van Every wrote:
> > Mozilla has made public the code I worked on for them.
> > https://bugzilla.mozilla.org/show_bug.cgi?id=416982 It is an
> > incomplete
e_file is performed, the single
backslashes that escape the whitespace are lost. "\ " turns into " ".
If you were to string(REPLACE "\\" "" out "${in}") for all your
paths before performing the configure_file, I think you would solve
the
a CMake
build system. I was unable to complete it for them. Volunteer open
source developers could probably complete it, however. The translator
is a big step in the right direction for tackling such a large build
tree.
Cheers,
Brandon Van Every
ERBATIM)
> >
> I think you have forgot the ARGS argument
ARGS is old school. Not necessary anymore.
I think someone forgot to convert the paths to native Windows paths.
Use file(TO_NATIVE_PATH path result)
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
ll"
> is immaterial.
It was your explanation, not mine. I agreed with your explanation. I
think your choice of words is material. You have also sought to
explain me as "Machiavellian." I acquiesced to that explanation in
order to bring peace.
Cheers,
Brandon Van Every
_
I apologized on the Lua list.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
e word "we," I
meant the CMake community. In context it was probably appropriate.
You are showing an unwillingness to agree to disagree, and you are
forgetting your own statement that "I mean well." Do you mean well?
Cheers,
Brandon Van Every
_
een around the block with a ponderous build,
surely you've got an inventory of ideas about how these behemoths go,
how you could better present the job to the client, and how you could
better manage the risk of it succeeding or failing.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
ld say, "Hey presto
here are some results!" Enough to make people realize that their
conversion isn't hopeless and imponderable, that all they really have
to do is dive in and clean up the translation output.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
tasks are enough.
Ok, so you're on record as having your doubts and thinking this
wouldn't work for you. I suppose that's a data point and dealing with
skepticism is an issue. Anyone else feel more bullish about this?
Otherwise I guess it's not an open source problem. Mo
On Feb 8, 2008 11:30 AM, Jesper Eskilson <[EMAIL PROTECTED]> wrote:
>
> Brandon Van Every wrote:
> > Someone asked me the other day why CMake doesn't do this. I thought I
> > gave him a reasonable answer, that it would be painful to do, and that
> > CMake -->
e true for MSVC, plus MSVC changes its format every few
years. Does MSVC pose any other special difficulties, other than
sheer mind-numbingness of translation?
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
ack In Time and rant and rave to my 11 year
old self about what a horrible word "piracy" is?? The audacity of
those game developers, how dare they seek compensation by restrictive
technological means! We should burn all our Double Fannucci collecto
On Feb 5, 2008 6:49 PM, Alan W. Irwin <[EMAIL PROTECTED]> wrote:
> On 2008-02-05 17:08-0500 Brandon Van Every wrote:
>
> > On Feb 5, 2008 4:28 PM, Alan W. Irwin <[EMAIL PROTECTED]> wrote:
> >>
> >> I looked at that site, and there was no mention of an el
have filed http://cmake.org/Bug/view.php?id=6295 on this
issue. A CMake newbie needs enough free documentation to become an
intermediate user. After that, they can choose to RTFM, grep sources,
read mailing list archives, or buy books. I don't think they need to
get everything that anyone woul
On Feb 5, 2008 2:30 PM, Bill Hoffman <[EMAIL PROTECTED]> wrote:
>
> The 4th edition CMake books have arrived and you can order them from
> http://kitware.com/products/cmakebook.html
I've ordered. Am I first? Do I get a cookie?
Cheer
On Feb 5, 2008 2:15 PM, Hendrik Sattler <[EMAIL PROTECTED]> wrote:
> Am Dienstag 05 Februar 2008 schrieb Brandon Van Every:
>
> > On Feb 5, 2008 11:08 AM, Hendrik Sattler <[EMAIL PROTECTED]> wrote:
> > > Quoting Brandon Van Every <[EMAIL PROTECTED]>:
>
On Feb 5, 2008 11:08 AM, Hendrik Sattler <[EMAIL PROTECTED]> wrote:
>
> Quoting Brandon Van Every <[EMAIL PROTECTED]>:
> > On Feb 5, 2008 10:05 AM, John Spray <[EMAIL PROTECTED]> wrote:
> >>
> >> If I were invoking a second CMake, would I be able to
mething. You'd have to know what that
output is going to be, and how to invoke the build.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
'd have to take over linking
manually with some kind of add_custom_command, however you usually get
it to work. Why do you need the foreign code embedded in the host
library? Wouldn't shipping libraries for multiple platforms be
enough?
Cheers,
Brandon Van Every
_
On Feb 4, 2008 3:09 PM, Bill Hoffman <[EMAIL PROTECTED]> wrote:
> Brandon Van Every wrote:
> >
> > But my question is *why* must -P be the last thing? Is this a design
> > flaw, or is there some shell reason for it?
> >
>
> I think it is so you can hav
cache is
not modified. If variables are defined using -D, this must be done
before the -P argument.
But my question is *why* must -P be the last thing? Is this a design
flaw, or is there some shell reason for it?
Cheers,
Brandon Van Every
___
CMake mailin
E_CURRENT_BINARY_DIR}/SVN_REVISION
Otherwise an out of source build fails.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
AND CMAKE_CFG_INTDIR STREQUAL "/Debug")
set(wingui)
endif(MSVC AND CMAKE_CFG_INTDIR STREQUAL "/Debug")
# use this style for all add_executable calls
add_executable(foo ${wingui} blah.c etc.c)
Cheers,
Brandon Van Every
>
> Surya
> ___
k they should be removed as true/false values.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
to the
commands will be passed exactly as specified no matter the build tool
used. Note that one level of escapes is still used by the CMake
language processor before ADD_CUSTOM_TARGET even sees the arguments."
Cheers,
Brandon Van Every
___
CMak
s wiki entry: "Note that CMAKE_BUILD_TYPE is not
initialized with a readable value at configuration time. This is
because the user is free to select a build type at build time. Use
CMAKE_CFG_INTDIR if you need a variable that evaluates to the correct
build time directory. "
Cheers,
Bran
NG_MAKE_FLAGS), is added.
>
> The above works fine, the only pain is that I have to edit the build.make
> file every time I re-run the cmake command. The question is, how can this be
> automated by cmake commands?
string(REGEX REPLACE ...)
Cheers,
Brandon Van Every
_
rew
energy at the problem, there was no known solution. Unless the latest
greatest MSVC is doing something different.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
l. Generally I just give the 1..2
sentences necessary, and someone else goes through the bother of
getting it into the docs. I think that's as it should be, since for
such small changes, constructing and applying patches is useless
overhead for all parties.
Cheer
ot set this unless you
have an exceptionally good reason to.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
problem with, you've skipped around from command to command to
command. By "trivial" I mean 1 line of mis-translating text, not a
dump of whatever project you're working on.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
On Jan 28, 2008 12:16 AM, Alan W. Irwin <[EMAIL PROTECTED]> wrote:
> On 2008-01-27 22:28-0500 Brandon Van Every wrote:
>
> > On Jan 27, 2008 8:34 PM, Alan W. Irwin <[EMAIL PROTECTED]> wrote:
> >> I would like to be able to read arbitrary environment variables f
...
>
> Now if I go and check the configure log, I see that the LDFLAGS are
> interpreted as "-L${PROJECT_SOURCE_DIR}/lib\ -ldl" (watch the escaping
> of the " " (space)).
Did you try VERBATIM?
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
. It doesn't exist in the build environment,
as CMake is gone and we're not running under CMake's choice of shell
anymore. This gotcha should also be noted in the set() docs.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
On Jan 24, 2008 2:50 PM, Andreas Pakulat <[EMAIL PROTECTED]> wrote:
>
> Any ideas how to solve this (besides upgrading cmake)?
Quotes?
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
1 - 100 of 663 matches
Mail list logo
