Building from scratch. Part 2
(continued)
First, do you know where WOK name comes from ? It’s not just Workshop Organization Kit as named in the documentation. In Chinese cuisine wok is a deep convex pan in which chef cooks food (I’m sure you saw it, right ?) The name was given by a former Matra Datavision employee who was of Chinese origin and initiated it. WOK was used in MDTV in multi-site, multi-team, cross-platform environment who intensively worked on development of one product bundle (Euclid Quantum) that contained many components (including its foundation – CAS.CADE). The source base was huge, release cycles were asynchronous and this could not fit into one source control repository that would permanently built. Take into account state of the art hardware of that time (slow Sun workstations, networks, etc). So development environment had to reflect that and WOK really enabled that dispersed and hierarchical environment. You could take a piece of software and put into your local workbench or creates a tree of workbenches and develop.
Time passed, Euclid Quantum dissolved, CAS.CADE transformed into Open CASCADE, but WOK is still alive though not developed anymore. It’s pure legacy, and current investment into it would unlikely be justified. WOK still does its job enabling cross-platform and multi-team software development but it’s way too heavy for that. It’s like if you used a truck to drive to your office one mile away from your home.
In terms of building time WOK does not stand any competition with VS which builds in parallel threads. Building Data Exchange module in Release mode on quad-core Xeon processor took 13 minutes where WOK was crunching for 32.
My personal view on development environment is that you should borrow what is available outside. Don’t re-invent a wheel when others produce good ones you can freely use. There are options available out there, with wide adoption, with active evolution. Go and grab some. In our team in Intel we use SVN and SCONS-based build system (of course, with custom tweaks to setup a whole infrastructure around it – promotion process, unit and integration tests, build rotation, etc). I heard Google’s Chrome also uses SCONS. There are also cmake, qmake (Qt-tailored) and likely many other decent options.
Migration has a cost, but if you count long term benefits, you can change your mind. My humble opinion.
9 comments
I did try to compile using a single solution with VS2005 and VS2008. It works good, despide the fact that intellisense will use your CPU for a long time period :) You can try to disable intellisense if you want.
ReplyDeleteAlso, I have created a new configuration to build static libs and these works good.
QbProg
Hi, Roman! I saw you mentioned Euclid Quantum. I've gone through all of the Internet to find something about this application, but there's no info. Do you know something? At least some screenshots?
ReplyDeleteHi Roman, I am very glad that you published part 2 so quickly, I was very excited after reading part 1 today ;-)
ReplyDeleteI am contributing to the Debian packaging of OpenCascade, and dug a bit into WOK to determine dependencies against header files and split packages into smaller pieces. That worked fine at the end, but has not been painless. I was wondering if we could use WOK to compile packages, mostly because upstream dropped Linux binaries and we do not know if Makefile.am support will continue, and partly because it is IMHO better to use the same build procedures as upstream.
Now, after reading your post, it is not clear at all whether spending more time on learning WOK makes sense. It looks like all we need to generate Makefile.am files is to parse EXTERNLIB, FILES and PACKAGES files, I will investigate this route.
Hello Denis, I would advise you to rely on GNU build tools which are provided with OCCT. Though WOK is actually used as internal development environment, makefiles are supported on a regular basis and in fact this is a way that release of OCCT is built on multiple Linux systems. Using WOK on Linux is troublesome, you will need to dig really *very deeply* into it to make it working. Note that parsing EXTERNLIB and other files is far not sufficient to mimic WOK behaviour.
ReplyDeleteThanks Andrey, your comments are very helpful. I had to fix WOK as described in http://bugs.debian.org/501352 to generate header files, this is all I needed at that time. I will buy your advice and stay away from WOK ;-)
ReplyDelete(*) 2 QbProg:
ReplyDeleteThanks, that was good to know. I was lazy to create a cumulative solution and to set correct dependencies ;-). Perhaps OCC could consider this for the future.
(*) 2 Svetlozar:
Try google "Matra Datavision Euclid Quantum", it returns about 2000 entries. It was planned as new full CAD/CAM/CAE/PLM suite to compete with others at that time. After MDTV acquisition by Dassault Systemes and change of the business focus, the product was discontinued in 1999.
Some orphan screenshots are left in .\samples\standard\mfc\03_2DSamples\03_4_2DImage\Data\. Enjoy ;-)
(*) 2 Denis:
Andrey made a good answer that explains the status.
My unified OCC build for VS2008 can be found at http://qtocc.svn.sourceforge.net/viewvc/qtocc/occ630/ros/adm/win32/vc9/
ReplyDeleteJust in case for those who use Scons (or interested in it), our team at Intel has just open sourced the Scons extension, called Parts - http://parts.tigris.org. It comes with detailed PDF document. We use this extension to enable concurrent development of multiple product components.
ReplyDeleteGoogle has released a build tool based on Scons that enables parallel cross-platform building, unit tests, etc. Likely something worth analyzing for those who have a build headache http://code.google.com/p/swtoolkit/
ReplyDelete