OCE 0.1.0 released

Hello Author,

What a pity OpenCascade team does not provide a respectable community environment around OCC.
To this regard I just want to say that OCE seems a very nice piece of work, great job !

I will surely use it instead of the "official" and broken version.

I'm used OCC last 3 years and I have more that 100 patches for this. I'm try to use this patches on the forum, but no answer... Maybe my patches is needed for OCE project.
For the sample, I'm remove the double headers too, also I don't use any configure.in and other files, only Qt *.pro project files and more... On linux and windows. All my sources of OCC no more 20 mb of disk space.

If need my working I'm may upload this.

Hi Yuriy,

Your contribution is welcome, it's exactly in that intent that the OCE project was created.

We have set up a basic development workflow that is based upon git branching/merging and atomic commits. It's quite efficient. Please join the oce-dev googlegroup to discuss this topic and your patches at http://groups.google.com/grou/oce-dev

Best Regards,

Author

Hello Yuriy,
1.We have thoroughly checked the Forum contents for the last few years searching for your name in order to find the patches you posted. We were able to find just one contribution from you concerning HLR optimization : http://www.opencascade.org/org/forum/thread_20320/. If you could point us to your other postings where you send us your patches, we would be very much obliged.
As for the HLR patch, unfortunately, your correction cannot be used as is. It would be great if you could check it against the current OCCT version 6.5 and send us an update in the standard form on the basis of "diff" command.
2.Using this case I would like to stress once again that we are open for any relevant contribution and ready to consider it as soon as you provide it, naturally, within certain limitations of our productive plans and business context.
3. The fact is that, to integrate any patch, we must invest a lot of efforts into its industrial non regression testing, and this time-consuming job cannot be performed in the on-line mode.
So, please, be patient, be positive and be sure that we will not lose any input from the community, that really improves OCCT. The reason for our commitment is very simple – it is our business.

Regards
Commenter-3

Ok, I'm I don't try to create any problem for commercial OCC project. Here is more that one patch. All my previous working about memory leaks, some additional viewer function and texturize. I'm start with OCC and now I'm use this like Training.
I believe in the success of the project OCC and very grateful for the basic knowledge which he provides. But because I consider it my duty to share developments with OCC developers. I'm live in N.Novgorod and can provide their development at personal meeting, if necessary or in electronic form.

Thanks in advance, for Your extensive work in development. I am sure that this is not in vain.

Yuriy, could you please email me at Commenter-4 dot lygin at gmail dot com ?

(All: sorry for the off-topic message but there is no way to send a private message. Would be good to have this feature on the forum.)

Sergey, like month ago I change my name from Commenter-2 to Yuriy Sinithin. And that a reason why you can't find all my patches and work here.

Also I make OCC emf export under Linux with libEMF.

Are you saying that you have made .pro files for the whole project and are using qmake to build the OCC :)? That's really cool, it's really easy to make the OCC build in all platforms. Would it be possible that you would share your work?

Qt OCC sources:
http://www.opencascade.org/org/forum/thread_19175/

Here is Qt sources for OCC 6.5 but here more modification, more that 10000 headers is not using, only base classes:

Foundation
ModelingAlgorithms
ModelingData
Visualization
and some part of ApplicationFramework

Hi Yuriy,
We found both your accounts and made a new attempt to find your patches having this fact in mind.
For the moment we found the patches for HLR (19520), qmake pro files (19175) and OpenGl module (19334).
We ask you to point us to the exact threads where you proposed other your patches, in case if there are any not listed above.
Concerning the updated version of qmake files (Qt.zip) we unfortunately can't accept it because:
- it covers only 28 packages (OCCT has ~ 500 packages)
- at the moment we use WOK for this.
Nevertheless we will take it into account as an idea planning upgrades of OCCT building tools.
Thank you.
Commenter-6

Oh wow and thank you very much! I wish that I'll be able to contribute to your effort at some point.

Hi Juhani,

For your information, a CMake based build system is being developed at OCE. It is based upon the outdated opencascade-cmake project (http://code.google.com/p/opencascade-cmake/), that was merged into the OCE git repository.

This cmake builder is currently available from the master branch, and is planned to be released with the 0.2 oce version (see https://github.com/tpaviot/oce/wiki/Roadmap).

Author

Hi Author,

Thanks for the reply....I know about the CMake based build system for OCE, I've been following it for some time.

Ok, there are two reasons why I am personally excited of Yuriy Sinithin's qmakefiles. First, I've worked both with cmake and qmake and I prefer qmake (matter of personal taste, basically they do the same thing, I just think that project maintenance with qmake is easier).

Second, I use QtCreator as my #1 IDE, so using qmake to build all the libraries makes also sense. All UI's I do with Qt.

Would it be too much of a trouble if OCE were able to support both cmake and qmake?

Hi Juhani,

We've been moving to CMake, which is already a big work to achieve. Don't know if the benefit from adding qmake support deserves such an important additional effort. IMO, let's go with *one* build system that is stable, well maintained rather than dispatching our skills and efforts into many different directions.

Note however that the git repository is open to anyone wishing to contribute the project. If you or Yuriy want to share your work, you're welcome. The integration of your qmake development branch to the master branch will then be discussed.

It's just my opinion, this has to be discussed on the oce-dev list: http://groups.google.com/group/oce-dev. Feel free to post a feature request.

Author

Hi Author,

I totally understand you considering the effort been made to set up the cmake build system.

One possible option that I can think of is to make the secondary effort live in it's own folder (only the files of the secondary build-system) and use a script that would move (q)makefiles to proper positions. So keeping those up to date would on the shoulders of a person/persons who wish to maintain that.

I haven't done anything yet, it's Yuriy who has done a great deal of work putting those files together, so it would be nice get it finished and availlable for those who find it usable.

Juhani

Hi Juhani,

The idea here is the CMake also offers a window to CPack [ platform independend packaging -> installers ] and perhaps even CTest in the near future. So, ultimately its more beneficial to focus the effort on a "single" [ since cmake can output for xcode, ms visual studio, make ] build strategy, that makes things much more coherent and saves a lot in development effort. The idea is to do it once well, so that the many disparitive efforts become a thing of the past.

-jelle

Ok! I don't understand how CMake and CPack working. It's not user option. I don't think that anybody use this. For the sample: why you are create your OCC project with Visual Studio Project file ? It's cool under Windows, see all sources, may find any errors . But what about me and I think more users of this forum: WE DON'T USE M$ and WE DON'T WANT TO USE .vcproj.
How we can edit sources ? after some file changed, then edit configure.in, configure.am, and other... I'm click start in OCC Creator and thats all.

I make this OCC sources project for me, for my work. If it needed for any project: OCC or OCE I may create full project. Here is only one problem: I don't have any mac system to test build under OS X.

If you share the Qt-based compilation project, I'm sure that Mac-users would be willing to test it out on their machine. I for one would prefer a qmake-based solution, but that's just an opinion.

I have taken a look at your pro-files and noticed that most of these files share quite some amount of configuration, which could be gathered centrally in pri-files.

I have used qmake in the past to generate make-files for a non OCC program during my PhD. The same pro-file was also usable to generate Visual Studio solution (wrote a bat-file for it) and XCode Projects (wrote a sh-script) from the same sources, so I could compile on Linux using make, on Windows using Visual Studio and on OSX using XCode. I regenerated the XCode and Visual Studio projects when changes occur in the Pro files. With some preparation you can get pretty far with this (e.g. compiler directives, setting output folders, all linking, include VS manifests etc...). You don't need the .vcproj files, but you can generate them if you use Visual Studio.

But I guess that would also be feasible with CMake.
I have used it (to compile things) but never configured CMake files.
I wasn't aware of the Packing options.

Why not integrate both? Have Pro-files as an option for people who prefer it?

>Why not integrate both?

DRY

Hi Stefan,

"Why not integrate both? Have Pro-files as an option for people who prefer it?"

My vote for that also. Does the idea of qmake files living in its own folder, make any sense?

Juhani

Hi Yuriy,

At least I can help with that, I'm on multiple platforms and have a mac :). Wish just that there was a centralized place for your makefiles to live in....so that one could pull them from svn or similar.

Juhani

P.S. for those who use VS, it is possible to create vsproj-files from qmake-files, as you propably knew. Also projects for xcode.

>I'm on multiple platforms and have a mac

me++

>Wish just that there was a centralized place for your makefiles to live in....so that one could pull them from svn or similar

that's the OCE / CMake objective precisely.

"that's the OCE / CMake objective precisely."

Yes, i know :). I was referring to qmakefiles.

BR, Juhani

Hi jelle,

I know that cmake offers some things that qmake does not and vice versa. And in most cases it is a question of personal preference what one wishes to use. And in many cases many users do not care as long as what is offered, works :). But for some people it makes the difference.

Would it be ok to think that if there is people who want to maintain, lets say the qmake build system, there would be some place for the project to live within OCE? Separate folder for example.

A separate branch could be an option. I kindly ask you to move this discussion to the OCE mailing list [ see top of this thread ].
OCE tries to cater for all needs of the community, but this topic is quite specific. I'm sure Dennis Barbier & Author will have an opinion too.
See you on the OCE list!

Ok, haven't signed into the list yet, I'll have to do that. See you!

BR, Juhani

Very good news! I'm glad that OCE project started and live.
Thanks all developers (OCC and OCE)!