2009/11/7 Simon Loic <simon1l...@gmail.com> > Hi, Arun , Thomas >
Hi Loïc, Sorry I didn't reply faster to this post. > > >> b) I had to add /usr/lib64/python2.6/site-packages/OCC.pth for python to >> find files in the site-packages/OCC directory >> > > >> Weird. Did you append this path to your sys.path? What Linux distro do > you run? gcc/swig versions? > > I think this is due to a recent change on debian like distribution : I've > seen somewhere that they decided to have the same name for local and system > python packages : > While before the directories were named > -- /usr/lib/python2.6/dist-packages > -- /usr/local/lib/python2.6/site-packages > > Now they are names : > -- /usr/lib/python2.6/dist-packages > -- /usr/local/lib/python2.6/dist-packages > > On my side, I decided to link site-package towards dist-packages > If what I say is true for all distribution, then maybe it makes sens to > change setup.py to install in distpackage by default on linux distribution. > As I told Arun, I have the same config as you for python packages directory (I run Ubuntu Linux). But it seems to be different on OpenSuse. > > BTW, I've seen that there was a plan to develop a building system based on > scons. I don't know anything about scons, but just out of curiosity, have > you considered cmake too? If so, what made you prefer scons? I don't have > much time right now to spend on this project but my experience with cmake is > that it is very friendly and handle major platforms very well. IMHO it is a > very good choice if not the best when targeting multiplatform projects. > Up to now, the pythonOCC compilation process is performed with distutils. I ran a few tests with SCons, but I was not convinced by the solution. I didn't see any benefits from using it rather than distutils, but it may come from the fact than I don't enough know SCons to do something fully optimized. So I decided to remove the SCons script from the pythonOCC svn trunk. I chose to test SCons because it's pythonic, but you're right, I should have considered other building solutions and first realize a benchmark. CMake is of course a also very good solution, but I don't have any skill related to that product. Trying to have a real multipatform building system, as well as packaging the solution for all available platforms, is according to me an issue, but also a very important work to achieve in order to make the pythonOCC library the easiest way to start with OCC. I confess it's not the funniest game I've ever played, and it's a hugely time consuming activity. On the other side, I think it's not the best way for me to add value to the pythonOCC project: in my job, I'm focused on mechanical engineering/design/production issues. "The right man at the right place" is a key concept of project management. In a few words, I'm not the man. I have to find someone would could do it. regards, > Best regards, > > Loïc > > > Thomas > _______________________________________________ > Pythonocc-users mailing list > Pythonocc-users@gna.org > https://mail.gna.org/listinfo/pythonocc-users > >
_______________________________________________ Pythonocc-users mailing list Pythonocc-users@gna.org https://mail.gna.org/listinfo/pythonocc-users
