Sounds like us scons people need to try out cmake. See how good it
is. I don't have time now, but will try to get to it. Also need to
look at how easy it is to maintain, that's one of the really nice
things about scons.
Joe
On Thu, Jan 14, 2010 at 6:04 AM, Miguel A. Figueroa-Villanueva
wrote:
As mentioned before, I think one of the key benefit of cmake is the ability
to generate solution/project files. This might be not be a huge deal to
seasoned coders, but for beginner coders who just wants to explore the
Blender source code a bit, having an IDE like Visual Studio really helps.
-mik
I'll throw my opinion in, if any one wants it. I'm quite new to the blender
sources and when I initially checked out blender I followed the instructions to
build using scons. This worked perfectly first time and I was happy. When I
started playing with things, I set up scons as an external build
re: CMake 'just working', I think the problem is developers who use
use CMake make sure it works on their systems but since there are less
mac/windows developers using cmake, or their configurations vary a
(MSVC versions Im guessing)... At a given time CMake may be broken on
these systems. Even if
I use msvc for source editing and debugging, and scons for compiling.
Build systems don't have to replace project files, I use scons mostly
because there's more control that way for what I do.
Joe
On Thu, Jan 14, 2010 at 2:28 PM, Mike Pan wrote:
> As mentioned before, I think one of the key bene
joe wrote:
> I use msvc for source editing and debugging, and scons for compiling.
> Build systems don't have to replace project files, I use scons mostly
> because there's more control that way for what I do.
>
And if the project files were updated along with the Scons build files -
that is al
How about those projectfiles_vc9? A working cmake should make them redundant.
It would be great if Andrea Weikert (Elubie) and Benoit could switch
from manual updating those projectfiles_vc9 (and vc7) to cmake.
That would help cmake in Blender quite a bit I think.
Cheers,
Erwin
Out of curiosity:
I used to occasionally use the manually maintained project files, but
then I learned that cmake could generate them and I've been using
those since.
Cheers,
Mitchell Stokes (Moguri)
On Sat, Jan 16, 2010 at 8:30 AM, Erwin Coumans wrote:
> How about those projectfiles_vc9? A working cmake should m
Yeah it's fairly common iirc. I do, and I know of at least two other
devs who have done the same.
I think the problem here is none of us have time to test cmake
thoroughly to evaluate it, and I'm not sure how many other devs have
had the same speed issues I have, that motivates me to evaluate cma
Hi Erwin,
Erwin Coumans schrieb:
> How about those projectfiles_vc9? A working cmake should make them redundant.
>
yes, if the projectfiles generated by cmake would work as well as the
manually maintained ones, they would probably be redundant.
However, I have repeatedly tried to generate a wo
Andrea,
I tested current trunk on Windows and cmake debug build and release
just compiles and runs fine, if you use default settings.
Did you change any cmake defaults (such as enabling OpenCollada which
is OFF by default)?
Did you file an issue with details in the bug tracker (with full
c
Hi Erwin,
Erwin Coumans schrieb:
> Andrea,
>
> I tested current trunk on Windows and cmake debug build and release
> just compiles and runs fine, if you use default settings.
>
Well, the default settings have only part of the features enabled. What
if I want to debug/test these?
> Did you c
Ok, I got fed up with all the discussion about a broken cmake Win32 debug build,
so I fixed it in svn revision 26055. The fix is to put 'debug' or
'optimized' before the library name.
cmake OpenCollada is now enabled by default for a bit of testing.
If other devs like to disable it again, it is tr
I have also been using the CMake files with MSVC for the past year or
so in Debug and Release.
It takes a bit of tweaking, but so do most build systems.
I also think scons is fantastic for getting a build up quickly and
simply, but as many people have pointed out project files are great
for develo
Full long is here if anyone needs it:
http://blenderartists.org/~theeth/bf/meeting-newdev-09-12-06.txt
Martin
--- On Sun, 12/6/09, Roger Wickes wrote:
> From: Roger Wickes
> Subject: [Bf-committers] New Developer Meeting Minutes
> To: "bf-blender developers" ,
> bf-scripts-...@blender.org
>
Can this be a further summarized?
if it reads like Tons meeting notes it could be posted on BN also.
On Sun, Dec 6, 2009 at 6:04 PM, Martin Poirier wrote:
> Full long is here if anyone needs it:
>
> http://blenderartists.org/~theeth/bf/meeting-newdev-09-12-06.txt
>
> Martin
>
> --- On Sun, 12/6/0
Hi Campbell,
--- On Mon, 12/7/09, Campbell Barton wrote:
> Can this be a further summarized?
I've wikified the very cool RNA/Operators "lessons" you, theeth and dingto
made at the NewDev meeting, see
http://wiki.blender.org/index.php/Dev:Doc/Blender_Source/RNA
and
http://wiki.blender.org/index.
Dev Q&A session would be Jan 3 (5 days from now). Im ok to be in 1hr
before the meeting to answer questions.
Anything we need to arrange/announce... etc? (Anyone know how to use
Blender nations new self publishing system?)
___
Bf-committers mailing list
Hello,
--- On Tue, 12/29/09, Campbell Barton wrote:
> Anything we need to arrange/announce... etc? (Anyone know
> how to use
> Blender nations new self publishing system?)
I've "announced" it here
http://www.blendernation.com/yournews/development/next-new-developer-meeting-sunday-3-january-2010
Roger Wickes wrote:
>
> We held our second monthly new developer
> meeting(http://wiki.blender.org/index.php/Dev:SundayMeetingAgenda/NewDev_meetings)
>
> on Sunday, attracting x new developers to the Blender family.
> Minutes are here:
> http://wiki.blender.org/index.php/Dev:SundayMeetingAgen
The build system topic took most of the meeting or so and I hope we
dont let this happen again or the new dev meetings will get very
uninteresting.
Please next time try to avoid arguing about stupid topics like this
while we are trying to give basic info to new devs.
I think topics like this just
Sorry to say that but on win32 systems meanwhile Cmake fails just to begin to
compile anything with free MSVC versions, scons works correctly.
jms.
Selon Campbell Barton :
> The build system topic took most of the meeting or so and I hope we
> dont let this happen again or the new dev meetings w
Never had any problems with cmake since the beginning of cmake support, look
at
http://www.geneome.com/blender-tutorials/building-blender-with-msvc-using-cmake/
There is all the information you need to do the compilation. I try on winxp,
vista and now windows 7 with the free edition of msvc ide.
2
The only bad think is cmake file is not always up to date in some branch and
need correction to do the compilation.
2010/1/7 lguillaume
> Never had any problems with cmake since the beginning of cmake support,
> look at
> http://www.geneome.com/blender-tutorials/building-blender-with-msvc-using-
The fact that cmake can create visual studio projects, Xcode projects
and makefiles should make scons, make and manual msvc project
maintenance obsolete.
It is a pity people don't maintain/fix cmake.
Thanks,
Erwin
Sent from my iPhone
On Jan 7, 2010, at 1:56, Campbell Barton wrote:
> The bu
Do the makefiles it generate handle dependency updates correctly?
That's the big reason I use scons, and why it's survived I think.
Joe
On Thu, Jan 7, 2010 at 6:22 AM, Erwin Coumans wrote:
> The fact that cmake can create visual studio projects, Xcode projects
> and makefiles should make scons,
Yes it does. You just need to make sure that the headerfiles are
included in the CMakeLists.txt
Are the dependencies broken in cmake generated unix makefiles? If so,
it could and should be fixed U think. In out Bullet library it works
all fine.
Thanks,
Erwin
Sent from my iPhone
On Jan 7,
Bummer iPhone automatic spelling fixer ;)
It should be fixed I think. It works fine in our Bullet library.
New developers (and myself) can browse and debug code much easier in
an IDE such as msvc, Xcode or K develop, in my opinion. And manual
updating projectfiles is a waste of time.
Thanks,
--- On Thu, 1/7/10, Erwin Coumans wrote:
> New developers (and myself) can browse and debug code much
> easier in
> an IDE such as msvc, Xcode or K develop, in my opinion. And
> manual
> updating projectfiles is a waste of time.
It's very easy to use Eclipse (with CDT) with scons. K Develo
Same for cmake, but scons doesn't support Xcode or msvc.
So to me it seems cmake should be primary build system, and scons just
for the die hard fans.
On Jan 7, 2010, at 6:52, Martin Poirier wrote:
>
>
> --- On Thu, 1/7/10, Erwin Coumans wrote:
>
>> New developers (and myself) can browse and
Not sure what dependency updates are exactly - if files are added you
need to run "cmake ." in the build dir but aside from that I never had
any dep propblems.
I'm tempted to install Windows just to get rid of the MSVC Project
files and have CMake create propper debug builds... it cant be that
har
--- On Thu, 1/7/10, Campbell Barton wrote:
> @Martin, my experience with using scons and eclipse isnt so
> good, it
> works OK but a bit annoying to setup, I recall I needed to
> have
> eclipse call a shell script that called scons.
You were doing it wrong then.
The only thing you need to do
cmake can create msvc and xcode projectfiles.
scons cannot do this, and seems slower incremental builds (according to
Campbell).
This justifies fixing any remaining issues with cmake/CMakeLists.txt files I
think.
>> I'm tempted to install Windows just to get rid of the MSVC Project
>> files and h
Hy,
Just giving my input as a (trying to be) new dev:
CMake is in fact quicker for incremental build but scons is used buy a lot
by people that just want to build svn, and I think there is a reason to
this: It is simpler to get started with and most of the doc for building
blender refer to scons.
Campbell Barton schrieb:
> Not sure what dependency updates are exactly - if files are added you
> need to run "cmake ." in the build dir but aside from that I never had
> any dep propblems.
>
> I'm tempted to install Windows just to get rid of the MSVC Project
> files and have CMake create propper
2. the include path for quicktime_export.h is wrong in the generated
> projectfiles. I tried to fix this but after experimenting with the
> CMakeList files for an hour just decided to wait for someone more
> familiar with the cmake files.
>
> - Andrea
>
> The fix for this problem :
Index: source/
Since this thread is now about build systems, can we please change the
subject line?
Ken
Campbell Barton wrote:
> Not sure what dependency updates are exactly - if files are added you
> need to run "cmake ." in the build dir but aside from that I never had
> any dep propblems.
>
> I'm tempted to
By the way, if OpenCollada breaks the cmake build system, it should be
disabled I think.
Hopefully that motivates someone who needs OpenCollada to fix it.
Can someone disable OpenCollada by default it in cmake?
Thanks,
Erwin
2010/1/7 Ken Hughes
> Since this thread is now about build systems,
So in cmake, do you have to include the header paths or actually list
the header files themselves?
Joe
On Thu, Jan 7, 2010 at 3:37 PM, Erwin Coumans wrote:
> By the way, if OpenCollada breaks the cmake build system, it should be
> disabled I think.
> Hopefully that motivates someone who needs Op
All headerfiles have to be included, either manually (each by name) or using
a wildstar (using GLOB). I suppose GLOB with a wildcard is what you refer to
as 'header paths'?
Thanks,
Erwin
2010/1/9 joe
> So in cmake, do you have to include the header paths or actually list
> the header files the
Really? I was pretty sure you just have to make sure the header paths
are set using SET(INC path1 path2 ...)), and it's only source files
that have to be explicitly named or wildcarded.
-Nicholas
On Sat, Jan 9, 2010 at 2:18 PM, Erwin Coumans wrote:
> All headerfiles have to be included, either m
No, you need to specify the headerfiles (either by individual name or GLOB *
wildcard)
for dependencies and certain features to work properly
(for example MSVC won't find definitions properly (right-click 'goto
definition'),
if headerfiles are missing from the cmake generated projectfiles.
Thanks,
INC is to tell the compile what include directories to use. Without it the
source won't compile.
If you don't specify the headerfiles, the source compiles, links and runs,
but
dependencies and program database (MSVC) won't work properly.
2010/1/9 Erwin Coumans
>
> No, you need to specify the h
Ah, my bad.
-Nicholas
On Sat, Jan 9, 2010 at 4:50 PM, Erwin Coumans wrote:
> INC is to tell the compile what include directories to use. Without it the
> source won't compile.
>
> If you don't specify the headerfiles, the source compiles, links and runs,
> but
> dependencies and program database
Yeek. That's horrible. I wonder how hard would it be to write some
utility code for the cmakefiles that scans for #include statements.
This sort of thing is exactly why I stick with scons, despite it's
horrific speed problems. :-/ I'm even tempted to rewrite our scons
files to use waf instead s
You can avoid the work by adding a GLOB * wildcard for header files,
but explicitly specifying every individual file seems recommended indeed.
Once you have the cmake project up and running, you usually only add a few
.cpp or .h files at a time,
so the incremental effort usually isn't much.
This
When I generate an MSVC project with CMake, the header files are in
the project, dependencies seem to be taken into account correctly,
wildcards are used to automatically add/remove files, .. is there an
actual problem here?
Brecht.
On Sun, Jan 10, 2010 at 10:53 PM, Erwin Coumans wrote:
> You ca
The is no problem using GLOB with a wildcard, as I mentioned at least
times in this thread ;)
But explicitly listing each file seems recommended, I forgot why.
Perhaps GLOB needs to search for (potential) new headerfiles, every
time you build and a .cpp changed (slowing down things unnecesar
On Mon, Jan 11, 2010 at 1:17 PM, Erwin Coumans wrote:
> The is no problem using GLOB with a wildcard, as I mentioned at least
> times in this thread ;)
>
> But explicitly listing each file seems recommended, I forgot why.
> Perhaps GLOB needs to search for (potential) new headerfiles, every
> time
The stackoverflow answer seem to confirm there are some dependencies and
performance issues with GLOB.
I'm interested to hear what the 'official' recommendation is by the cmake
developers.
Cheers,
Erwin
2010/1/11 José Ignacio
> On Mon, Jan 11, 2010 at 1:17 PM, Erwin Coumans
> wrote:
> > The i
>From the CMake mailinglist:
http://www.cmake.org/pipermail/cmake/2009-July/030535.html
"The problem with globbing is that CMake has no way to determine that new
source (or header) files were added to a directory, other than ALWAYS
running when someone types 'make' (or the VS equivalent). This
I'd rather not have to manually add headers. IMHO it's evil, and was
a gigantic pain in the old scons files (it's *so* much easier to not
have to do this for source or header files).
Anyway, if glob works that's fine, so long as it's smart enough to
figure out which headers are used by which sour
On Mon, Jan 11, 2010 at 10:10 AM, Erwin Coumans wrote:
> Just don't complain that dependencies don't reliably work, or that
> cmake is a bit slow :-)
>
> I follow the advice of the CMake developers for the Bullet project,
> and I'm happy with it.
This isn't convincing me that CMake is any better
@joe, From my experience cmake doesnt require you to do more clean
builds then scons. The only thing is is dependencies change "cmake ."
needs to run again in the build dir, building after only does a
partial build like scons.
If I understand this correctly, only generating the Makefiles is
slower
>> it (cmake) may generate project files, but I don't use that
It sounds a little bit selfish, there are many developers who want to use
project files.
>> and our scons setup could be setup to do the same thing as well.
Can scons create decent MSVC and Xcode project files? Who maintains such
pro
Does it run automatically or do you have to run it yourself?
Joe
On Mon, Jan 11, 2010 at 1:53 PM, Campbell Barton wrote:
> @joe, From my experience cmake doesnt require you to do more clean
> builds then scons. The only thing is is dependencies change "cmake ."
> needs to run again in the build
I wasn't saying we should abandon support for projectfiles. My point
is that cmake must perform on the command line build workflow as well
as project file workflows. And that support for projectfiles doesn't
make it great for command line (and vice versa).
I wasn't advocating generating project
ah, ok, I would have been interested in open source scons project file
generation.
(actually at Havok we had scons create cross-platform project files,
but these extensions were kept in-house)
As far as I know, cmake works very well for both command line and
projectfiles.
I still haven't heard a
Selon joe :
>
> I wasn't advocating generating project files from our scons system,
> heh. I'm all for replacing scons, actually, either by rewriting our
> scons wrapper and infrastructure to use waf, or replacing it with
> cmake if cmake is good enough.
>
Here, cmake exports a project if it is
Cmake can create projectfiles for any version of MSVC, as long as that
version of MSVC is installed.
It should work from any drive letter, it is not restricted to C:
Otherwise, please use the cmake support channels.
Thanks,
Erwin
2010/1/11
> Selon joe :
>
> >
> > I wasn't advocating generatin
Selon jmso...@free.fr:
> Selon joe :
>
> >
> > I wasn't advocating generating project files from our scons system,
> > heh. I'm all for replacing scons, actually, either by rewriting our
> > scons wrapper and infrastructure to use waf, or replacing it with
> > cmake if cmake is good enough.
> >
>
There should be no problem with disk location or msvc version using cmake
either.
Have you seriously tried to find a solution?
I'm surprised of so much resistance among the Blender developers
to such a nice build system as cmake.
Thanks,
Erwin
2010/1/11
> Selon jmso...@free.fr:
>
> > Selon
That's what I was trying to figure out, whether it's as good as scons
or not. It sounds like it might be comparable, so I'm going to try it
as soon as I get time. If it is, I'll be very happy, since for all
it's ease of use and maintenance, scons really is super slow.
Joe
On Mon, Jan 11, 2010 a
Erwin Coumans wrote:
> Have you seriously tried to find a solution?
>
> I'm surprised of so much resistance among the Blender developers
> to such a nice build system as cmake.
Agreed. There seems to be quite a few posts *looking for* problems with
CMake... I have not found any problems with CMake
Well, it's had a rough start and some of us are wary of using it
exclusively without assurance it's not going to be a step backwards :)
I also think the fact that it generates makefiles makes some of us
initially nervous, since makefiles are usually synonymous with
"immensely painful and difficult
But of course I'm going to look into it more now, I would love to be
able to not have to deal with the sheer slowness of scons.
Joe
On Mon, Jan 11, 2010 at 3:26 PM, joe wrote:
> Well, it's had a rough start and some of us are wary of using it
> exclusively without assurance it's not going to be
Just to say that I successfully made a 64 bits compilation of blender with
vc2010 beta 2010 and cmake 2.8.
Can anyone put the patch for correcting quicktime dir in cmake (anyone who
can test if it does not break on mac) :
Index: source/blender/makesrna/intern/CMakeLists.txt
==
Selon Benjamin Tolputt :
> Erwin Coumans wrote:
> > Have you seriously tried to find a solution?
> >
> > I'm surprised of so much resistance among the Blender developers
> > to such a nice build system as cmake.
>
> Agreed. There seems to be quite a few posts *looking for* problems with
> CMake...
2010/1/12 Erwin Coumans :
> I'm surprised of so much resistance among the Blender developers
> to such a nice build system as cmake.
>
> Thanks,
> Erwin
We can also reverse the question - we have a very nice and working
SCons system. Why would you want to get rid of the nice system I
created?
"I'
>> We can also reverse the question - we have a very nice and working
>> SCons system. Why would you want to get rid of the nice system I
>> created?
I have not asked mentioned to get rid of scons, but asked to fix cmake,
because cmake can create MSVC, XCode and other project files.
scons cannot
2010/1/12 Erwin Coumans :
>>> In any case, lets just make sure Blender gets better, ok?
> Improving cmake is a great start in making Blender better.
And so is improving SCons.
/Nathan
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists
Committed in svn 25921.
CMake build worked on Mac before & after the patch :)
Damien
Le 12 janv. 2010 à 03:48, lguillaume a écrit :
> Just to say that I successfully made a 64 bits compilation of blender with
> vc2010 beta 2010 and cmake 2.8.
>
> Can anyone put the patch for correcting quickti
jmso...@free.fr wrote:
> If cmake was so marvelous, it should work easily on any system
> but it don't without "serious search". That's what I experimented
> and others users that do not post on this list too ( LG knows that
> it's true).
>
I have found CMake to work without problems on all my
On 12.1.2010, at 8.39, Nathan Letwory wrote:
> 2010/1/12 Erwin Coumans :
>> I'm surprised of so much resistance among the Blender developers
>> to such a nice build system as cmake.
>>
>> Thanks,
>> Erwin
>
> We can also reverse the question - we have a very nice and working
> SCons system. Why
If there's people willing to maintain for their own respective compile systems,
I don't see the issue.
I suppose collectively, our efforts are split, but that's the nature of open
source projects. Different
people with different systems, goals, etc.
Mike Belanger ( Mikahl )
www.watchmike.ca
On Tue, Jan 12, 2010 at 2:51 AM, Mats Holmberg wrote:
> On 12.1.2010, at 8.39, Nathan Letwory wrote:
>> 2010/1/12 Erwin Coumans:
>>> I'm surprised of so much resistance among the Blender developers
>>> to such a nice build system as cmake.
>>>
>>> Thanks,
>>> Erwin
>>
>> We can also reverse the que
76 matches
Mail list logo
