[Bf-committers] moving i18n from UI_interface to blenkernel
Hi, A Brecht's commit regarding nodes (41633) broke the i18n process (IFACE_(name) works at execution time, but xgettext has no way to find the strings to translate). That is a small glitch indeed, but it raises a problem that we’ll have too when it comes to translating messages (BKE_report and co): with this commit, I need to use IFACE_ in node_[composite/shader/texture]_tree.c, and I don’t think including UI_interface.h here is good! (We already have an #include UI_interface.h /* bad level call into editors */ in bpy_rna.c...) Hence, the question: would it be a good idea to move the i18n macros and funcs from UI to BKE (e.g. place them into BKE_blender.h)? If so, I’m volunteering ;) Best regards, Bastien ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Icon scaling
Hi, On 08.11.2011 04:08, Campbell Barton wrote: Firstly I think the main issue with getting this into blender is finding someone with the time who wants to work on this. I was kind of offering to do it, but I would have to experiment with my rendering code, to implement the shape hinting in the first place. Or else it provides no benefit to scaled down bitmaps. I have no idea if I even have the time, but it's one of the things I would love to work on, and I just wanted to gauge interest after seeing that Blender could benefit from this. Regarding implementation - Even if the icons render fast, we would still need to pass them to OpenGL, while probably not _really_ slow doing this every draw, its a step backward from using a textures which are fast. I'd expect we would end up doing something similar to fonts where the vector data generates a texture at different sizes. Yes, the generated bitmaps would have to end up in some cache, or it would be too expensive. One may even want to put them into a persistent cache so it doesn't slow down program startup each time. That being said, the rendering is really extremely fast. In Haiku, we do have an icon cache based on the resulting bitmaps in the file manager, but the first time icons are needed, they are loaded from disk as vector icons, parsed from the format into the shape data model and then rendered. It seems that the reduced disk size compared to PNGs or other formats, and thus faster loading time compensates the additional rendering time. At least I was careful not to introduce a perceptable delay when working on this stuff. However at this point we can probably just get away with using larger icons - 32x32 for eg - and it will be `good enough`, That may indeed be the case. Something else to consider when updating the icon system is to allow addons to use their own icons. To understand what problem you are referring to, I would have to become familar with the codebase. :-) btw - With SDL1.3 you should be able to run blender, though I'm not sure how far along the SDL1.3 port is. I was helping to mentor the GSoC project to port SDL 1.3 to Haiku, reviewing the patches and providing a lot of input. It's another item on my TODO list to help improve this more, but I am pretty sure our OpenGL implementation needs more work in general, SDL is just another client of that API and whether or not it is used directly or indirectly, it needs to improve. :-) Thank you for your feedback! Best regards, -Stephan ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] moving i18n from UI_interface to blenkernel
Just talk with sergey about this on IRC. He suggested to move that i18n stuff to BLF rather than BKE. But this means we’ll likely have to import from BLF in many parts of Blender (nodes, modifiers, RNA, etc.). Would it be acceptable? Le 08/11/2011 10:07, Bastien Montagne a écrit : Hi, A Brecht's commit regarding nodes (41633) broke the i18n process (IFACE_(name) works at execution time, but xgettext has no way to find the strings to translate). That is a small glitch indeed, but it raises a problem that we’ll have too when it comes to translating messages (BKE_report and co): with this commit, I need to use IFACE_ in node_[composite/shader/texture]_tree.c, and I don’t think including UI_interface.h here is good! (We already have an #include UI_interface.h /* bad level call into editors */ in bpy_rna.c...) Hence, the question: would it be a good idea to move the i18n macros and funcs from UI to BKE (e.g. place them into BKE_blender.h)? If so, I’m volunteering ;) Best regards, Bastien ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Worth a look? Open Source Raytracer from Intel
A short look at the Embree Raytracer from Intel gives me the impression that it is fairly similar to Cycles. It was released as open source under the Apache License, Version 2.0. Maybe it can provide some good hints for some improvements. The project and source code can be found here: http://software.intel.com/en-us/articles/embree-photo-realistic-ray-tracing-kernels/ Greetings from Tobias Oelgarte ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Including documentation in BCon cycle
On Tue, Nov 8, 2011 at 7:53 AM, f.paglia...@gmail.com wrote: I'm not a developer so I see your suggestion from an artist point of view: It's an incredile pain try to figure out how a tool works! Really, I think here in our studio we spent dozen of hours in testing, defining our own ideas of what is done by a tool without really know if what we imagine is true. And this in many situation lands to not use that tool but just find another way to do something that works! I agree in the relationship: No docs = not ready for trunk Maybe it's time to hire someone to get a well documented wiki ;) Funny, I was thinking the same thing as I fell asleep last night. One person in charge of finding the problems and talking with the devs, coordinating of the writers and pulling together all the docs, links, blogs, vids, books and manuals into a cohesive, updated whole would be a god send! -- Douglas E Knapp Creative Commons Film Group, Helping people make open source movies with open source software! http://douglas.bespin.org/CommonsFilmGroup/phpBB3/index.php Massage in Gelsenkirchen-Buer: http://douglas.bespin.org/tcm/ztab1.htm Please link to me and trade links with me! Open Source Sci-Fi mmoRPG Game project. http://sf-journey-creations.wikispot.org/Front_Page http://code.google.com/p/perspectiveproject/ ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Including documentation in BCon cycle
Hi, On 11/08/2011 03:18 PM, Knapp wrote: Maybe it's time to hire someone to get a well documented wiki ;) Funny, I was thinking the same thing as I fell asleep last night. One person in charge of finding the problems and talking with the devs, coordinating of the writers and pulling together all the docs, what you are saying above is OK for the wiki. As it's being discussed in docboard and #blenderwiki: * we're now reviewing the 2.5 manual (not in good shape at all) * we'll install a reviewing system * we'll define a team of reviewers with the rights to accept edits made in wiki, so that the content users will see is always ok * for each blender module (modeling, rigging, etc), we intend to find a 'main' (not exclusive) reviewer that will take care of: * review and and format contents inserted by devs * review content inserted by occasional editors * hunt for new editors (experienced in blender possibly) * these modules reviewers will have to communicate with the main admins (more on this later) to make sure the manual structure/templates/etc are agreed upon. This should be a team work. Though, IMO the first input should come by the developer, which should write even just a draft (no wiki formatting) the tool documentation. Otherwise you get the current problems, also outlined by Francesco. The potential writer has to discover the tool by trial and error, then find the strength to formalize what he has discovered, format it in good wikitext, using blenderwiki templates. Honestly, that's a lot to ask. links, blogs, vids, books and manuals into a cohesive, updated whole would be a god send! I think this is not a good idea. Two examples: * deadlinks are a nigthmare to maintain * you can't paste a book or a blog page in the wiki without permission IMHO The wiki should not phagocytize the whole web, but rather be a good reference with its own identity and direction. We should not trash everything in, but rather make a good team work, and refine communication channels: devs - wiki admins - writers team - users, also formalizing this in the BCon, so that documentation is not an boring optional, but part of the job of the developer. Surely with insights from devs the doc will become much more appealing also to professional users and companies :) Regards, Luca _ http://wiki.blender.org/index.php/User:Mindrones http://www.mindrones.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [41631] trunk/blender/extern/libmv: Hopefully compilation with MinGW will work again.
Hi Joshua, it looks like a stack issue with gcc. Please update your MinGW environment with latest mingw-get-inst. In my case loading from latest MinGW repositories during install solved the issue(gcc 4.6.1 included). Right now the trunk should be fully compilable with MinGW. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Including documentation in BCon cycle
On Tue, Nov 8, 2011 at 1:32 PM, Knapp magick.c...@gmail.com wrote: On Tue, Nov 8, 2011 at 3:52 PM, mindrones mindro...@gmail.com wrote: Hi, On 11/08/2011 03:18 PM, Knapp wrote: Maybe it's time to hire someone to get a well documented wiki ;) Funny, I was thinking the same thing as I fell asleep last night. One person in charge of finding the problems and talking with the devs, coordinating of the writers and pulling together all the docs, what you are saying above is OK for the wiki. As it's being discussed in docboard and #blenderwiki: * we're now reviewing the 2.5 manual (not in good shape at all) That is for sure. One of the reasons I really liked Blender was the 2.4 manual. It was great. I wonder why? * we'll install a reviewing system * we'll define a team of reviewers with the rights to accept edits made in wiki, so that the content users will see is always ok * for each blender module (modeling, rigging, etc), we intend to find a 'main' (not exclusive) reviewer that will take care of: * review and and format contents inserted by devs * review content inserted by occasional editors * hunt for new editors (experienced in blender possibly) * these modules reviewers will have to communicate with the main admins (more on this later) to make sure the manual structure/templates/etc are agreed upon. This should be a team work. Though, IMO the first input should come by the developer, which should write even just a draft (no wiki formatting) the tool documentation. Otherwise you get the current problems, also outlined by Francesco. The potential writer has to discover the tool by trial and error, then find the strength to formalize what he has discovered, format it in good wikitext, using blenderwiki templates. Honestly, that's a lot to ask. Ya but at the same time lots of us do 30-90 minute vids. links, blogs, vids, books and manuals into a cohesive, updated whole would be a god send! I think this is not a good idea. Two examples: * deadlinks are a nigthmare to maintain Yes, but they are all OK on Wikipedia and could be here too with the right set up. * you can't paste a book or a blog page in the wiki without permission Clearly a push not pull situation. I think authors and bloggers would be happy to try and keep a link page up to date if they knew it was there and the users knew it was the first place to stop when looking for something. Blender.org should be the first or second place (behind Google) that users go for their info. As it stands, it is about the last place I go but it used to be the first. On the other hand we already have the books. Did you know that? I know it took me a long time to find them when I knew they were there! These are some great sources of info! They SHOULD be very easy to find with Google but they are not. http://wiki.blender.org/index.php/Doc:2.5/Books http://wiki.blender.org/index.php/Doc:2.4/Books IMHO The wiki should not phagocytize the whole web, but rather be a good reference with its own identity and direction. I think we should keep in mind that we have a manual and it should be THE source of good info and then we have a wiki. (I know the two overlap) We should not trash everything in, but rather make a good team work, and refine communication channels: devs - wiki admins - writers team - users, also formalizing this in the BCon, so that documentation is not an boring optional, but part of the job of the developer. I have long thought that documentors should be recognized for what they do just as devs are. I truly can't say a dev is more important than a doccer in a mature program like blender. The program lives and dies based on both sides of the work. Surely with insights from devs the doc will become much more appealing also to professional users and companies :) The biggest problem that I see with blender is the new user coming to blender and that leaving because they are so over loaded and can't find good help or docs. God knows we have a great program but without good intros newbies will leave. I got over this hump because of graybeards vids on the gui. I can't wait to do my first ship sailing on the open seas with cycles rendering of the animation! And think of the blood effects you could do with dynamic paint! On the other hand what do I use for water? There are now like 6 ways to do it! LOL. I can just see dynamic paint particles impacting the top of my sea and spreading out in ripples with my old time ship reflecting in the water! I would love to know how you do grass in Cycles! :-) Regards, Luca True. I have told friends about Blender, and many gave up after a day or two because of frustration from above reasons. -- Douglas E Knapp Creative Commons Film Group, Helping people make open source movies with open source software!
Re: [Bf-committers] Including documentation in BCon cycle
I must agree that the documentation is way behind where it should be. Maybe LetterRip's plan for Google winter of documentation could help there? ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Including documentation in BCon cycle
Hey all, quick note: I started this thread because I wanted to discuss specifically about developers involvement in the documentation of the stuff they code. Thoughts and ideas about the documentation in general should be sent to the docboard mailing list, not here. Not answering is ok (it is an answer by itself after all :P ), while losing focus can be quite a waste of time! Regards, Luca _ http://wiki.blender.org/index.php/User:Mindrones http://www.mindrones.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] grading w/ compositor
Hi I am desperately missing the time to finish my OpenColorIO integration and other opensources stuff I wass doing before. I hope this situation will change in a few weeks/months. In the meantime being the coder of the scopes here is my toughts: - *Scopes are slow* I don't know if they are threaded or not, but I found out that having the scopes open in image viewer really slow down the computing time. To be honest when doing a primary to bring the footage at a neutral stage (white balance, saturation, ...) I pretty much only look at the RGB waveform and the Vector Scope. (never trust what I see in the image viewer output). Moving a param in my comp (which basically have only one input, one RGB curves and one viewer, and waiting 1 or 2 sec for everything to update is not really efficient. I wonder if that cannot be faster ? With big resolution it is slow indeed. The indea was to make it use a background job so that it does not freeze the UI while updating (threading is also an option). I had a patch in the tracker for this but due to some update notifier problem it was causing lots of redraw of the image and scope regions so it was never applied to trunk, maybe now the situation is better and it is worth taking another look a it. - *Fine tuning is impossible* adding a point in the RGB curve and moving it slightly with the mouse to adjust white balance is really challenging and almost impossible to get perfect. perhaps there is shortcut to move the selected point which I'm not aware of. A suggestion would be to not limit the zoom in the compositor and be able to scale the nodes as much as we want to have a more accurate values on those. Another suggestion would be to display the coord of the selected point where we can enter some values ? Blender 2.4x style was to keep Shift pressed while draging for better precision. This seems to have disapeared in some places since 2.5 - *Min/Max of waveform are difficult to see* the 3 lines on the right of a waveform defines the max and min of each channels. a good way to start to white balance your footage is by trying to have those 3 lines on the same level. Right now they are kind of hard to see. I don't know if we can make them bigger or find a better display for it I don't find them hard to see, but as the original coder of the scopes I had some feedback where people do not understand that it is min/max and tought it was garbage. This king of style customusation is easy for anybody with C/OpenGL knowlage, but it would be better to have a clear goal before messing the code just for personal ahesteic preferences. Also the scopes permits scaling but not panning, it would be good to add panning to them. The problem: those key combination are hard coded and not configarable by the user keymap. xat ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Please help me debugging
Hi, If you are new to debugging I recommend to use QTCreator like described here: http://wiki.blender.org/index.php/User:Ideasman42/CMakeQTCreatorLinux It has a very nice integrated GUI to gdb, easy to use and still powerfull. Here is the documentation: http://doc.qt.nokia.com/qtcreator-2.3/creator-debugging.html It also have a very nice GUI for Valgrind memcheck and callgrind utils. xat 2011/11/5 Rainer Hohne raho...@googlemail.com Hi there, being quite new to debugging, I would be glad if you could explain to me how to trace function calls from the GUI. Currently I can only see what function blender is at when it crashes (using DDD on Ubuntu), but I need to know which C function is being called for example if I click a certain button in the GUI. So can someone please explain what I need to do to get such a live backtrace of GUI interactions (if possible at all) - do I need a debug build of python or something like that ? Rainer ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] grading w/ compositor
*With big resolution it is slow indeed. The indea was to make it use a* * background job so that it does not freeze the UI while updating (threading is also an option). I had a patch in the tracker for this but due to some update notifier problem it was causing lots of redraw of the image and scope regions so it was never applied to trunk, maybe now the situation is better and it is worth taking another look a it.* - are they computed if collapsed (since we can't really close them) ? by that I mean, if I collapse all of them except the waveform, it is the only one computed ? *I don't find them hard to see, but as the original coder of the scopes I* * had some feedback where people do not understand that it is min/max and tought it was garbage. This king of style customusation is easy for anybody with C/OpenGL knowlage, but it would be better to have a clear goal before messing the code just for personal ahesteic preferences.* the min/max makes perfect sense to me and the design is great. I just feel like its hard to see especially when you want to make those lines match. Plus they disappear in those rounded corners which is a bit annoying. maybe it is the default grey background which makes it hard to see it. Like I almost didn't noticed the grid and values with the light gray ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Worth a look? Open Source Raytracer from Intel
Looking sweet! You should also post this on the Bf-Cycles list. On Tue Nov 8 11:05:43 2011, Tobias Oelgarte wrote: A short look at the Embree Raytracer from Intel gives me the impression that it is fairly similar to Cycles. It was released as open source under the Apache License, Version 2.0. Maybe it can provide some good hints for some improvements. The project and source code can be found here: http://software.intel.com/en-us/articles/embree-photo-realistic-ray-tracing-kernels/ Greetings from Tobias Oelgarte ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] grading w/ compositor
Than maybe the better would be to add themes options for the backgroung and grid colors for the scopes. thought about it, but it won't solve the issue, I think some kind of fix background behind the lines should be there. so no matter what funky theme you got, you can still see them ? xat ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- François Tarlier www.francois-tarlier.com www.linkedin.com/in/francoistarlier ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [41685] trunk/blender/build_files/scons/ config/win64-vc-config.py: Scons:
Hi,
This looks a bit strange for me. In theory, '${BF_OIIO}/include' and
'#../lib/win64/openimageio/include' should be the same paths and using
${BF_OIIO} is more flexible for build systems (at least for linux).
Maybe error was in how this path is used by SConstruct?
Thomas Dinges wrote:
Revision: 41685
http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=41685
Author: dingto
Date: 2011-11-08 21:17:42 + (Tue, 08 Nov 2011)
Log Message:
---
Scons:
* Fixing x64 compile with Cycles.
Modified Paths:
--
trunk/blender/build_files/scons/config/win64-vc-config.py
Modified: trunk/blender/build_files/scons/config/win64-vc-config.py
===
--- trunk/blender/build_files/scons/config/win64-vc-config.py 2011-11-08
20:56:55 UTC (rev 41684)
+++ trunk/blender/build_files/scons/config/win64-vc-config.py 2011-11-08
21:17:42 UTC (rev 41685)
@@ -157,15 +157,16 @@
WITH_BF_OIIO = True
BF_OIIO = LIBDIR + '/openimageio'
-BF_OIIO_INC = '${BF_OIIO}/include'
+BF_OIIO_INC = '#../lib/win64/openimageio/include'
BF_OIIO_LIB = 'OpenImageIO'
BF_OIIO_LIBPATH = '${BF_OIIO}/lib'
+BF_OIIO_LIBPATH = '#../lib/win64/openimageio/lib'
WITH_BF_BOOST = True
BF_BOOST = LIBDIR + '/boost'
-BF_BOOST_INC = '${BF_BOOST}/include'
+BF_BOOST_INC = '#../lib/win64/boost/include'
BF_BOOST_LIB = 'libboost_date_time-vc90-mt-s-1_47
libboost_filesystem-vc90-mt-s-1_47 libboost_regex-vc90-mt-s-1_47
libboost_system-vc90-mt-s-1_47 libboost_thread-vc90-mt-s-1_47'
-BF_BOOST_LIBPATH = '${BF_BOOST}/lib'
+BF_BOOST_LIBPATH = '#../lib/win64/boost/lib'
#Ray trace optimization
WITH_BF_RAYOPTIMIZATION = True
___
Bf-blender-cvs mailing list
bf-blender-...@blender.org
http://lists.blender.org/mailman/listinfo/bf-blender-cvs
--
With best regards, Sergey I. Sharybin
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [41687] trunk/blender: Cycles: cmake tweaks for linux build, instructions on the wiki no longer worked.
Since my commit removed BOOST define for linux, just a note that you
can use boosts find module search path, eg:
cmake -DBOOST_ROOT=/opt/boost .
On Wed, Nov 9, 2011 at 8:40 AM, Brecht Van Lommel
brechtvanlom...@pandora.be wrote:
Revision: 41687
http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=41687
Author: blendix
Date: 2011-11-08 21:40:08 + (Tue, 08 Nov 2011)
Log Message:
---
Cycles: cmake tweaks for linux build, instructions on the wiki no longer
worked.
Modified Paths:
--
trunk/blender/CMakeLists.txt
trunk/blender/intern/cycles/CMakeLists.txt
Modified: trunk/blender/CMakeLists.txt
===
--- trunk/blender/CMakeLists.txt 2011-11-08 21:24:32 UTC (rev 41686)
+++ trunk/blender/CMakeLists.txt 2011-11-08 21:40:08 UTC (rev 41687)
@@ -503,19 +503,12 @@
if(WITH_BOOST)
- # not sure this is needed, commenting, campbell
- # ---
- # set(BOOST /usr CACHE PATH Boost Directory)
- #
- # if(NOT BOOST_CUSTOM)
- # set(BOOST_ROOT ${BOOST})
- # set(Boost_USE_MULTITHREADED ON)
- # find_package(Boost 1.34 COMPONENTS filesystem regex
system thread)
- # endif()
+ # uses in build instructions to override include and library
variables
+ if(NOT BOOST_CUSTOM)
+ set(Boost_USE_MULTITHREADED ON)
+ find_package(Boost 1.34 COMPONENTS filesystem regex
system thread)
+ endif()
- set(Boost_USE_MULTITHREADED ON)
- find_package(Boost 1.34 COMPONENTS filesystem regex system
thread)
-
set(BOOST_INCLUDE_DIR ${Boost_INCLUDE_DIRS})
set(BOOST_LIBRARIES ${Boost_LIBRARIES})
set(BOOST_LIBPATH ${Boost_LIBRARY_DIRS})
Modified: trunk/blender/intern/cycles/CMakeLists.txt
===
--- trunk/blender/intern/cycles/CMakeLists.txt 2011-11-08 21:24:32 UTC (rev
41686)
+++ trunk/blender/intern/cycles/CMakeLists.txt 2011-11-08 21:40:08 UTC (rev
41687)
@@ -8,11 +8,10 @@
# Build Flags
-set(GCC_WARNING_FLAGS -Wall -Wextra -Wno-unused-parameter -Wno-long-long)
set(GCC_OPTIM_FLAGS -ffast-math -msse -msse2 -msse3 -mtune=native)
if(APPLE)
- set(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} ${GCC_WARNING_FLAGS}
${GCC_OPTIM_FLAGS})
+ set(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} ${GCC_OPTIM_FLAGS})
set(RTTI_DISABLE_FLAGS -fno-rtti -DBOOST_NO_RTTI -DBOOST_NO_TYPEID)
endif()
@@ -21,13 +20,13 @@
set(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} /Ox /Ot /arch:SSE2
-D_CRT_SECURE_NO_WARNINGS /EHsc /fp:fast)
set(RTTI_DISABLE_FLAGS /GR- -DBOOST_NO_RTTI
-DBOOST_NO_TYPEID)
elseif(CMAKE_COMPILER_IS_GNUCC)
- set(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} ${GCC_WARNING_FLAGS}
${GCC_OPTIM_FLAGS})
+ set(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} ${GCC_OPTIM_FLAGS})
set(RTTI_DISABLE_FLAGS -fno-rtti -DBOOST_NO_RTTI
-DBOOST_NO_TYPEID)
endif()
endif()
if(UNIX AND NOT APPLE)
- set(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} ${GCC_WARNING_FLAGS}
${GCC_OPTIM_FLAGS})
+ set(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} ${GCC_OPTIM_FLAGS})
set(RTTI_DISABLE_FLAGS -fno-rtti -DBOOST_NO_RTTI -DBOOST_NO_TYPEID)
endif()
___
Bf-blender-cvs mailing list
bf-blender-...@blender.org
http://lists.blender.org/mailman/listinfo/bf-blender-cvs
--
- Campbell
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
