I added a check if the output directory (../frozen) exists and will create
the directory if it does not exist.
This time I tested it also with the NaN make environment :)
Michel
is updated.
* modulefinder creates a file src.list which contains all the *.py files
needed for the python suport in Blender.
* Makefile.am is able to depend on the files listed in src.list.
* makemakefile_ac.py is reverted to the previous version. The old version
contained my first attempt to get the make freeze trick working. It was
wrong.
Michel
build systems (auto, msvc, PB) do not seem to have this problem.
- Change intern/python/freeze/Makefile to freeze outside of the source/ tree
- Change source/blender/bpython/Makefile to not build the frozen stuff anymore
- Change source/blender/bpython/intern/Makefile to use CURRENT_PYTHON_API
instead of FUTURE_PYTHON_API, damage control
I'm guessing its safe.
Basically it fixes a warning about typedef usage.
Reading the docs on gcc-3.2 it says that classes that use a typedef
need to have the keyword "typename" infront of them according to the c++
standard. Currently it only produces a warning but it may be an
error later, so I figured why not fix it.
Kent
*Fixed boolean buglet in the bsp lib. I have not committed any libraries so you'll
have to do this to see the changes in blender.
*Got the bsp test program working again with the new GHOST createWindow
interface.
*(Visual C++) Modfied some of the dsp in the intern library to NOT prompt when
overwirting old libs and header files. This is the /Y option after XCOPY
Cheers
Laurence.
didn't exist instead of installing it as it should.
- @../tools/cpifdiff.sh blenkey.h $(LCGDIR)/$(LIBNAME)/include/blenkey.h
+ @../tools/cpifdiff.sh blenkey.h $(LCGDIR)/$(LIBNAME)/include/
sgefant
clicking on it. The mouse up was already generated. They
are now balanced by mouse downs. The behaviour of the
OSX target now matches that of the WIN32 target.
Maarten
---------------------------->8----------------------------------------------
g++ -DHAVE_CONFIG_H -I. -I../../../blender/intern/bsp -I../.. -I../../../blender/intern/container -I../../../blender/intern/moto/include -I../../../blender/intern/memutil -I/usr/freeware/include -g -funsigned-char -c ../../../blender/intern/bsp/intern/BSP_CSGMesh.cpp -MT BSP_CSGMesh.lo -MD -MP -MF .deps/BSP_CSGMesh.TPlo -DPIC -o .libs/BSP_CSGMesh.lo
/usr/freeware/lib/gcc-lib/mips-sgi-irix6.5/3.0.4/include/g++/bits/stl_iterator.h: In
constructor `std::__normal_iterator<_Iterator,
_Container>::__normal_iterator(const std::__normal_iterator<_Iter,
_Container>&) [with _Iter = const BSP_MFace*, _Iterator = BSP_MFace*,
_Container = std::vector<BSP_MFace, std::allocator<BSP_MFace> >]':
../../../blender/intern/bsp/intern/BSP_CSGMesh.cpp:270: instantiated from here
/usr/freeware/lib/gcc-lib/mips-sgi-irix6.5/3.0.4/include/g++/bits/stl_iterator.h:474: cannot
convert `const BSP_MFace* const' to `BSP_MFace*' in initialization
*** Error code 1 (bu21)
*** Error code 1 (bu21)
*** Error code 1 (bu21)
*** Error code 1 (bu21)
---------------------------->8----------------------------------------------
The line in question that causes the error is the middle one in this group:
vector<BSP_MFace>::const_iterator f_it_end = FaceSet().end();
vector<BSP_MFace>::const_iterator f_it_begin = FaceSet().begin();
vector<BSP_MFace>::iterator f_it = FaceSet().begin();
Dropping the 'const_' from that middle line enables gcc to compile the
file correctly (this is also consistent with what is going on with other
parts of the file, i.e., stuff that is returned from a begin() method is
declared as vector<BSP_MFace>::iterator instead of
vector<BSP_MFace>::const_iterator.
But I'll be honest: I have no idea what this code does, so if somebody with
better C++ skills wants to check it, then please do.
This change was also tested to compile and run on debian linux/x86
(well, booleans are broken right now, so I wasn't able to do too much
testing).
Chris
I took out the following from the includes in the intern dir that still had
it:
-#ifdef HAVE_CONFIG_H
-#include <config.h>
-#endif
Kent
--
mein@cs.umn.edu
too -- a user reported crashing while using decimation and rolling back
the modifications between rev 1.2 and rev 1.3 for this file fixed it.
Regards,
Chris
