Re: [CMake] Automatic out of source build's possible?
On Tue, Feb 08, 2011 at 04:56:26AM -0500, Martin O'Brien wrote: > I definitely can't rely on the people who are complaining about having to do > the -D... to have the correct version installed, or even to recognize when > they don't, probably, and if I give them this option, they're going to write > scripts that depend on it. The basic problem is that although the users in > question think of themselves as developers, they're really not. They're > more IT'ish, involved in doing things like configuring continuous > integration servers, and I already get calls over things like > CMAKE_MINIMUM_REQUIRED() that they really ought to be able to figure out on > their own. So your question boils down to "how do I support users who won't read documentation or act on error messages in a useful way"? Let me know when you solve that one and I'll nominate you for some kind of prize in software engineering :). Anyway, as someone with an IT'ish background who does menial things like configure CI servers, my advice probably isn't worth much to a real developer like yourself. I'll go back to studying CMAKE_MINIMUM_REQUIRED(). tyler ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Automatic out of source build's possible?
I understand, but that's still a custom version for my purposes, at least for the time being. I definitely can't rely on the people who are complaining about having to do the -D... to have the correct version installed, or even to recognize when they don't, probably, and if I give them this option, they're going to write scripts that depend on it. The basic problem is that although the users in question think of themselves as developers, they're really not. They're more IT'ish, involved in doing things like configuring continuous integration servers, and I already get calls over things like CMAKE_MINIMUM_REQUIRED() that they really ought to be able to figure out on their own. That being said, how would I go about this? If some sort of patch were accepted, in time, I might be able to do this, once everybody upgraded. mm -Original Message- From: Eric Noulard [mailto:eric.noul...@gmail.com] Sent: Tuesday, February 08, 2011 4:39 AM To: Martin O'Brien Cc: cmake@cmake.org Subject: Re: [CMake] Automatic out of source build's possible? 2011/2/8 Martin O'Brien : > I've resisted the urge to patch, since I really don't want to be dependent > on a custom version of CMake. My idea was more like proposing a feature request + patch in order to make the feature go in upstream CMake. I cannot ensure it will but... > As far as how many people would like it, I don't know, but my guess would be > that most who were more familiar with configure or really anything that > Getopt long-ish than CMake would probably find it more familiar. this may be discussed by people listening to the list :-] My opinion is that it's sometimes annoying to have several ways to do something (-D OPT=ON vs --enable-opt) but it can ease the transition and/or some common place way to handle option on the command line. > What I've done in the past in a few cases where people complained mightily > (as well as pretty unreasonably, as this is hardly end of the world) was: > > -DCONFIGOPTS="--enable- --verbose --debug..." > > AND/OR > > -DCONFIGOPTSFILE= > > And then parse that/those (using a cmake module). Very ugly, but they could > usually handle that with much less complaining, and it also prevented > potential conflicts with cmake '--' options. I see. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Automatic out of source build's possible?
2011/2/8 Martin O'Brien : > I've resisted the urge to patch, since I really don't want to be dependent > on a custom version of CMake. My idea was more like proposing a feature request + patch in order to make the feature go in upstream CMake. I cannot ensure it will but... > As far as how many people would like it, I don't know, but my guess would be > that most who were more familiar with configure or really anything that > Getopt long-ish than CMake would probably find it more familiar. this may be discussed by people listening to the list :-] My opinion is that it's sometimes annoying to have several ways to do something (-D OPT=ON vs --enable-opt) but it can ease the transition and/or some common place way to handle option on the command line. > What I've done in the past in a few cases where people complained mightily > (as well as pretty unreasonably, as this is hardly end of the world) was: > > -DCONFIGOPTS="--enable- --verbose --debug..." > > AND/OR > > -DCONFIGOPTSFILE= > > And then parse that/those (using a cmake module). Very ugly, but they could > usually handle that with much less complaining, and it also prevented > potential conflicts with cmake '--' options. I see. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Automatic out of source build's possible?
I've resisted the urge to patch, since I really don't want to be dependent on a custom version of CMake. As far as how many people would like it, I don't know, but my guess would be that most who were more familiar with configure or really anything that Getopt long-ish than CMake would probably find it more familiar. What I've done in the past in a few cases where people complained mightily (as well as pretty unreasonably, as this is hardly end of the world) was: -DCONFIGOPTS="--enable- --verbose --debug..." AND/OR -DCONFIGOPTSFILE= And then parse that/those (using a cmake module). Very ugly, but they could usually handle that with much less complaining, and it also prevented potential conflicts with cmake '--' options. mm -Original Message- From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Eric Noulard Sent: Tuesday, February 08, 2011 3:44 AM To: Michael Wild Cc: cmake@cmake.org Subject: Re: [CMake] Automatic out of source build's possible? 2011/2/8 Michael Wild : > And there's the hidden trap that the -D options must be *before* the -P > option. Very nasty, especially for people who never used CMake before. Yes right I was caught by that in the past. > On 02/08/2011 09:27 AM, Martin O'Brien wrote: >> Absolutely, and that is what I do in some cases, but in the particular case >> that I described - which is what I had in mind; I should have been clearer - >> it doesn't help, as it's still -D... syntax. Ok then may be you can propose a patch for some generic --enable- --disable- cmake command line option that will be automatically translated to -D=ON seems do-able. I don't know if many people would like it ? -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Automatic out of source build's possible?
2011/2/8 Michael Wild : > And there's the hidden trap that the -D options must be *before* the -P > option. Very nasty, especially for people who never used CMake before. Yes right I was caught by that in the past. > On 02/08/2011 09:27 AM, Martin O'Brien wrote: >> Absolutely, and that is what I do in some cases, but in the particular case >> that I described - which is what I had in mind; I should have been clearer - >> it doesn't help, as it's still -D... syntax. Ok then may be you can propose a patch for some generic --enable- --disable- cmake command line option that will be automatically translated to -D=ON seems do-able. I don't know if many people would like it ? -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Automatic out of source build's possible?
Indeed. There's also just typing -DENABLE- instead of -DENABLE-=ON due to being used to --enable-. I find myself committing unintentionally all the time, and I've used CMake for a fairly long time. CMake of course flags it, but it's discouraging (IMO) to new users. mm -Original Message- From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Michael Wild Sent: Tuesday, February 08, 2011 3:32 AM To: cmake@cmake.org Subject: Re: [CMake] Automatic out of source build's possible? And there's the hidden trap that the -D options must be *before* the -P option. Very nasty, especially for people who never used CMake before. Michael On 02/08/2011 09:27 AM, Martin O'Brien wrote: > Absolutely, and that is what I do in some cases, but in the particular case > that I described - which is what I had in mind; I should have been clearer - > it doesn't help, as it's still -D... syntax. > > > mm > > -Original Message- > From: Eric Noulard [mailto:eric.noul...@gmail.com] > Sent: Tuesday, February 08, 2011 3:26 AM > To: Martin O'Brien > Cc: cmake@cmake.org > Subject: Re: [CMake] Automatic out of source build's possible? > > 2011/2/8 Martin O'Brien : >> While I too find myself sometimes wanting convenience scripts - some >> people find the use of '-DENABLE_=ON' instead of > --enable-' >> foreign, for example - the problem with them, IMO, is that they're >> impossible to make crossplatform without requiring the presence of >> some tool >> - perl, python, bash, whatever - on each system in a location that can >> be located pre-configure, which is exactly what using cmake gets you out > of. > > You can use CMake instead of perl, python etc... > you write your CMake script and then propose to the user to run, something > like: > > cmake -P easyBuild.cmake > > Many [portable] CMake commands are usable for that, mainly file( ...), > execute_process, string, message. > > As an example I did propose in the past a CMake script which can be used to > build a new CMake version (provided you already have one installed) with the > following single line: > > cmake -P CMake-autobuild.cmake > > You can write a similar cross-platform script(s) for your users. > It doesn't give you the possibility to use --enable but it's easy to use for > your user and is definitely cross-platform. > > If some options have to be chosen by the users they can either edit the > script or you may launch cmake-gui / ccmake at the end of the script in > order to give a chance to the user to select the choices. > > -- > Erk > Membre de l'April - « promouvoir et défendre le logiciel libre » - > http://www.april.org ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Automatic out of source build's possible?
And there's the hidden trap that the -D options must be *before* the -P option. Very nasty, especially for people who never used CMake before. Michael On 02/08/2011 09:27 AM, Martin O'Brien wrote: > Absolutely, and that is what I do in some cases, but in the particular case > that I described - which is what I had in mind; I should have been clearer - > it doesn't help, as it's still -D... syntax. > > > mm > > -Original Message- > From: Eric Noulard [mailto:eric.noul...@gmail.com] > Sent: Tuesday, February 08, 2011 3:26 AM > To: Martin O'Brien > Cc: cmake@cmake.org > Subject: Re: [CMake] Automatic out of source build's possible? > > 2011/2/8 Martin O'Brien : >> While I too find myself sometimes wanting convenience scripts - some >> people find the use of '-DENABLE_=ON' instead of > --enable-' >> foreign, for example - the problem with them, IMO, is that they're >> impossible to make crossplatform without requiring the presence of >> some tool >> - perl, python, bash, whatever - on each system in a location that can >> be located pre-configure, which is exactly what using cmake gets you out > of. > > You can use CMake instead of perl, python etc... > you write your CMake script and then propose to the user to run, something > like: > > cmake -P easyBuild.cmake > > Many [portable] CMake commands are usable for that, mainly file( ...), > execute_process, string, message. > > As an example I did propose in the past a CMake script which can be used to > build a new CMake version (provided you already have one installed) with the > following single line: > > cmake -P CMake-autobuild.cmake > > You can write a similar cross-platform script(s) for your users. > It doesn't give you the possibility to use --enable but it's easy to use for > your user and is definitely cross-platform. > > If some options have to be chosen by the users they can either edit the > script or you may launch cmake-gui / ccmake at the end of the script in > order to give a chance to the user to select the choices. > > -- > Erk > Membre de l'April - « promouvoir et défendre le logiciel libre » - > http://www.april.org ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Automatic out of source build's possible?
Absolutely, and that is what I do in some cases, but in the particular case that I described - which is what I had in mind; I should have been clearer - it doesn't help, as it's still -D... syntax. mm -Original Message- From: Eric Noulard [mailto:eric.noul...@gmail.com] Sent: Tuesday, February 08, 2011 3:26 AM To: Martin O'Brien Cc: cmake@cmake.org Subject: Re: [CMake] Automatic out of source build's possible? 2011/2/8 Martin O'Brien : > While I too find myself sometimes wanting convenience scripts - some > people find the use of '-DENABLE_=ON' instead of --enable-' > foreign, for example - the problem with them, IMO, is that they're > impossible to make crossplatform without requiring the presence of > some tool > - perl, python, bash, whatever - on each system in a location that can > be located pre-configure, which is exactly what using cmake gets you out of. You can use CMake instead of perl, python etc... you write your CMake script and then propose to the user to run, something like: cmake -P easyBuild.cmake Many [portable] CMake commands are usable for that, mainly file( ...), execute_process, string, message. As an example I did propose in the past a CMake script which can be used to build a new CMake version (provided you already have one installed) with the following single line: cmake -P CMake-autobuild.cmake You can write a similar cross-platform script(s) for your users. It doesn't give you the possibility to use --enable but it's easy to use for your user and is definitely cross-platform. If some options have to be chosen by the users they can either edit the script or you may launch cmake-gui / ccmake at the end of the script in order to give a chance to the user to select the choices. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Automatic out of source build's possible?
2011/2/8 Martin O'Brien : > While I too find myself sometimes wanting convenience scripts - some people > find the use of '-DENABLE_=ON' instead of --enable-' > foreign, for example - the problem with them, IMO, is that they're > impossible to make crossplatform without requiring the presence of some tool > - perl, python, bash, whatever - on each system in a location that can be > located pre-configure, which is exactly what using cmake gets you out of. You can use CMake instead of perl, python etc... you write your CMake script and then propose to the user to run, something like: cmake -P easyBuild.cmake Many [portable] CMake commands are usable for that, mainly file( ...), execute_process, string, message. As an example I did propose in the past a CMake script which can be used to build a new CMake version (provided you already have one installed) with the following single line: cmake -P CMake-autobuild.cmake You can write a similar cross-platform script(s) for your users. It doesn't give you the possibility to use --enable but it's easy to use for your user and is definitely cross-platform. If some options have to be chosen by the users they can either edit the script or you may launch cmake-gui / ccmake at the end of the script in order to give a chance to the user to select the choices. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org CMake-autobuild.cmake Description: Binary data ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Automatic out of source build's possible?
While I too find myself sometimes wanting convenience scripts - some people
find the use of '-DENABLE_=ON' instead of --enable-'
foreign, for example - the problem with them, IMO, is that they're
impossible to make crossplatform without requiring the presence of some tool
- perl, python, bash, whatever - on each system in a location that can be
located pre-configure, which is exactly what using cmake gets you out of.
Mm
On Feb 8, 2011 2:53 AM, "Michael Wild" wrote:
> That's not how CMake works. With CMake developers usually have many
> binary trees referring to one single source tree (optimized/debug, 32/64
> bit, with/without some optional dependencies, etc.). There is no good
> way that CMake could automate the choice of suitable name of the binary
> tree (and scons fails there too, IMHO). So, AFAIK, the design choice was
> to leave it up to the user.
>
> Some projects provide simple shell scripts or Makefiles to automate this
> for a few simple cases (much the way you do), but IMHO it's not worth
> the hassle... If somebody is tech-savvy enough to build from source, you
> can assume (s)he knows how to create a directory and what the CWD is.
>
> My 2c
>
> Michael
>
> On 02/08/2011 05:50 AM, Campbell Barton wrote:
>> For blender we currently support 2 build systems - SCons and CMake,
>> Quite a few technical users build from source on *nix just to get the
>> latest version and use scons, I suspect this is because scons
>> configures every time and its simple just to type "scons" in the
>> source dir and end up with a build.
>> We have SCons configured to do an out-of-source build by default with
>> a predefined directory.
>>
>> I wasn't aware of anything similar for CMake so I write a GNUmakefile
>> (included below) in the root source dir to do something similar for
>> CMake.
>> (note, we don't allow in-source builds at the moment so there is no
>> conflict with possible in-source makefiles).
>>
>> This makefile creates a per-defined out-of-source build dir if
>> necessary and runs make, since we explicitly list source files and
>> headers in the CMakeLists.txt cmake will re-configure if needed.
>>
>> So my questions are...
>> - Do other projects do this? is there some preferred way to do this?
>> - Is it possible to setup the CMakeLists.txt so the generated
>> makefiles are written to a directory other then the CWD?
>> - Is there any way to default to our-of-source build when running
>> "cmake ." in the source dir? (rather then aborting which is what we do
>> now).
>>
>> Probably our users should just get the hang on setting up out of
>> source builds but I think they like the convenience.
>>
>> #
>> # This Makefile does an out-of-source CMake build in ../build/`OS`_`CPU`
>> # eg:
>> # ../build/Linux_i386
>> # This is for users who like to configure & build blender with a single
command.
>>
>> # System Vars
>> OS:=$(shell uname -s)
>> OS_NCASE:=$(shell uname -s | tr '[A-Z]' '[a-z]')
>>
>> # Source and Build DIR's
>> BLENDER_DIR:=$(shell pwd -P)
>> BUILD_DIR:=$(shell dirname $(BLENDER_DIR))/build/$(OS_NCASE)
>>
>> # Get the number of cores for threaded build
>> NPROCS:=1
>> ifeq ($(OS), Linux)
>> NPROCS:=$(shell grep -c ^processor /proc/cpuinfo)
>> endif
>> ifeq ($(OS), Darwin)
>> NPROCS:=$(shell system_profiler | awk '/Number Of CPUs/{print
$4}{next;}')
>> endif
>> ifeq ($(OS), FreeBSD)
>> NPROCS:=$(shell sysctl -a | grep "hw.ncpu " | cut -d" " -f3 )
>> endif
>> ifeq ($(OS), NetBSD)
>> NPROCS:=$(shell sysctl -a | grep "hw.ncpu " | cut -d" " -f3 )
>> endif
>>
>>
>> # Build Blender
>> all:
>> @echo
>> @echo Configuring Blender ...
>>
>> if test ! -f $(BUILD_DIR)/CMakeCache.txt ; then \
>> mkdir -p $(BUILD_DIR) ; \
>> cd $(BUILD_DIR) ; \
>> cmake $(BLENDER_DIR) -DCMAKE_BUILD_TYPE:STRING=Release ; \
>> fi
>>
>> @echo
>> @echo Building Blender ...
>> cd $(BUILD_DIR) ; make -s -j $(NPROCS)
>> @echo
>> @echo run blender from "$(BUILD_DIR)/bin/blender"
>> @echo
>>
>> .PHONY: all
>>
>> #
>>
>> - Campbell
>
> ___
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Automatic out of source build's possible?
That's not how CMake works. With CMake developers usually have many
binary trees referring to one single source tree (optimized/debug, 32/64
bit, with/without some optional dependencies, etc.). There is no good
way that CMake could automate the choice of suitable name of the binary
tree (and scons fails there too, IMHO). So, AFAIK, the design choice was
to leave it up to the user.
Some projects provide simple shell scripts or Makefiles to automate this
for a few simple cases (much the way you do), but IMHO it's not worth
the hassle... If somebody is tech-savvy enough to build from source, you
can assume (s)he knows how to create a directory and what the CWD is.
My 2c
Michael
On 02/08/2011 05:50 AM, Campbell Barton wrote:
> For blender we currently support 2 build systems - SCons and CMake,
> Quite a few technical users build from source on *nix just to get the
> latest version and use scons, I suspect this is because scons
> configures every time and its simple just to type "scons" in the
> source dir and end up with a build.
> We have SCons configured to do an out-of-source build by default with
> a predefined directory.
>
> I wasn't aware of anything similar for CMake so I write a GNUmakefile
> (included below) in the root source dir to do something similar for
> CMake.
> (note, we don't allow in-source builds at the moment so there is no
> conflict with possible in-source makefiles).
>
> This makefile creates a per-defined out-of-source build dir if
> necessary and runs make, since we explicitly list source files and
> headers in the CMakeLists.txt cmake will re-configure if needed.
>
> So my questions are...
> - Do other projects do this? is there some preferred way to do this?
> - Is it possible to setup the CMakeLists.txt so the generated
> makefiles are written to a directory other then the CWD?
> - Is there any way to default to our-of-source build when running
> "cmake ." in the source dir? (rather then aborting which is what we do
> now).
>
> Probably our users should just get the hang on setting up out of
> source builds but I think they like the convenience.
>
> #
> # This Makefile does an out-of-source CMake build in ../build/`OS`_`CPU`
> # eg:
> # ../build/Linux_i386
> # This is for users who like to configure & build blender with a single
> command.
>
> # System Vars
> OS:=$(shell uname -s)
> OS_NCASE:=$(shell uname -s | tr '[A-Z]' '[a-z]')
>
> # Source and Build DIR's
> BLENDER_DIR:=$(shell pwd -P)
> BUILD_DIR:=$(shell dirname $(BLENDER_DIR))/build/$(OS_NCASE)
>
> # Get the number of cores for threaded build
> NPROCS:=1
> ifeq ($(OS), Linux)
> NPROCS:=$(shell grep -c ^processor /proc/cpuinfo)
> endif
> ifeq ($(OS), Darwin)
> NPROCS:=$(shell system_profiler | awk '/Number Of CPUs/{print $4}{next;}')
> endif
> ifeq ($(OS), FreeBSD)
> NPROCS:=$(shell sysctl -a | grep "hw.ncpu " | cut -d" " -f3 )
> endif
> ifeq ($(OS), NetBSD)
> NPROCS:=$(shell sysctl -a | grep "hw.ncpu " | cut -d" " -f3 )
> endif
>
>
> # Build Blender
> all:
> @echo
> @echo Configuring Blender ...
>
> if test ! -f $(BUILD_DIR)/CMakeCache.txt ; then \
> mkdir -p $(BUILD_DIR) ; \
> cd $(BUILD_DIR) ; \
> cmake $(BLENDER_DIR) -DCMAKE_BUILD_TYPE:STRING=Release ; \
> fi
>
> @echo
> @echo Building Blender ...
> cd $(BUILD_DIR) ; make -s -j $(NPROCS)
> @echo
> @echo run blender from "$(BUILD_DIR)/bin/blender"
> @echo
>
> .PHONY: all
>
> #
>
> - Campbell
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
