oce vs opencascade after license changes

[Michele Fiorentino]

HI to all,

I am getting back to oce after 1 year. I posted a similiar question in the past, but the license of main opencascade repository has changed lately. I am wondering again which are the real differences compared to the mainstream library. Please I would like to see in this forum a sticky tread with the differences compared to offcial. Anyway Good to see that both communities are pretty active lately.

Thanks!

[Epy]

If you are talking about licenses, both are LGPL v2.1 with an exception to compile/distribute non-LGPL'ed code with the LGPL'ed headers from OCCT. As far as other things go: OCE has many compiler warning and bug fixes over OCCT. OCE supports many more platforms and compilers than OCCT as well. Basically, OCE has a higher code quality than OCCT. Take a look at the commits on GitHub if you'd like to see the changes we make.

[Michele Fiorentino]

Thanks for the quick reply. It's a pity we have two communities. Seems to be that main opencascade development started again after some years of closure and slow downs. Maybe is because of oce that now something is moving again.

thanks

[Andrey Betenev]

Hello,

Let me comment on this [second try].

On 23.04.2014 21:24, Epy wrote:

If you are talking about licenses, both are LGPL v2.1 with an exception to compile/distribute non-LGPL'ed code with the LGPL'ed headers from OCCT. As far as other things go: OCE has many compiler warning and bug fixes over OCCT.

Regarding compiler warnings: building OCE 0.15 on Windows with Visual Studio, I get ~40 compiler warnings (depending on VC version and bitness).
OCCT builds with VC with 0 warnings since version 6.7.0.

I do not have comparable numbers on Linux and Mac OS X, but I am pretty sure OCCT 6.7.1 will yield less compiler warnings than current OCE.
It would be nice if someone could check this...

Regarding bug fixes: yes, OCE contains some fixes over OCCT code.
How many?
Taking that OCE issue tracker contains 440 closed issues (after 3 years of existence), and most of those are related to tweaking build system, I estimate count of functional changes in the code as not more than 50.
For comparison, in OCCT we have 40-80 commits to master branch per month, and half of them are bug fixes and improvements of functionality.

The real problem is that you do not know if something is fixed or broken in OCE.
To my knowledge, two last releases of OCE had major functionality like Boolean operations on NURBS or XML import/export severely broken, and no one seemed to notice that...
I can give a proof if you like.

Another problem is that even if good fix is made in OCE but not submitted to OCCT, it has all chances to be lost with the next merge with official OCCT release.

OCE supports many more platforms and compilers than OCCT as well.

OCCT officially supports 7 flavors of Linux, full range of desktop Windows, and four recent versions of Mac OS X.
Compilers supported are VS 2005-2013, GCC 4.x, ICC and CLang.

How many other platforms are supported by OCE?
From what I know, these are:

• MinGW
• Borland compiler
  

I guess OCE should also have more consistent configuration and install procedures on Linux systems.

Why not submitting relevant changes to OCCT so that all users benefit, and not to loose them by merge of the next OCCT release?

Basically, OCE has a higher code quality than OCCT.

Please reconsider taking into account my arguments above.

Take a look at the commits on GitHub if you'd like to see the changes we make.

What OCE has more w.r.t. OCCT is bindings with many additional tools, like Memcheck, Google Test, CPack, Travis-CI, etc.
However, does is work well?
I just clicked on green Travis-CI icon on main page of OCE in GitHub, and get to OCE page of Travis-CI
Here the build status is Ok (as I guess by its green color), but the log reads:

DRAWEXE is in /usr/bin, TKTopTest is in /usr/lib64/oce.
Somehow TKernel cannot dlopen libraries from there.

Fixes: ...

$ DRAWEXE
Draw[1]> Draw[2]> pload ALL
An exception was caught 0x7f7651614f63 : Draw_Failure: Could not open: TKTopTest; reason: libTKTopTest.so.8: cannot open shared object file: No such file or directory
** Exception ** 0x7f7651614f63 : Draw_Failure: Could not open: TKTopTest; reason: libTKTopTest.so.8: cannot open shared object file: No such file or directory

For me, it seems not really working...

Finally, what OCE does not include (I do not really understand why) are OCCT samples and documentation...

Coming back to original question on differences between OCE and OCCT, my opinion is:
- OCE is good place for experimenting with configurations and new tools, you can easily do some changes needed for your project
- OCCT is more strict for accepting contributions but is more robust, since we control quality and non-regression of each integration

Naturally my point of view is biased and I would be happy to know other opinions.

Getting more general, let's recall that forking OCE had been caused by OCCT project being not publicly visible.
Now we are completely open to participation of open source community and will be happy to see OCE people contributing.
This way two projects can converge for the common benefit.

Andrey

On Wednesday, April 23, 2014 8:50:15 AM UTC-7, Michele Fiorentino wrote:

HI to all,

I am getting back to oce after 1 year. I posted a similiar question in the past, but the license of main opencascade repository has changed lately. I am wondering again which are the real differences compared to the mainstream library. Please I would like to see in this forum a sticky tread with the differences compared to offcial. Anyway Good to see that both communities are pretty active lately.

Thanks!

--

[Thomas Paviot]

Dear all,

In my opinion, this kind of discussion can only leads to misunderstandings and poor level discussions. Epy wrote that OCE code quality is better than OCCT without any proof. As an employee from the OpenCascade company, Andrey used his right of reply in a way which is not the most diplomatic one (the travis-ci.org integration with github was achieved by Denis Barbier, who should rather be thanked for all his work) and without many convincing arguments ("I'm pretty sure that..." cannot be considered as a technical or scientific fact).

I suggest to consider this discussion as closed and move forward with constructive topics. Of course you're welcome Epy, Andrey, to keep going on contributing to this ml.

Best Regards,

Thomas

--
You received this message because you are subscribed to the Google Groups "oce-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to oce-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[D. Barbier]

On 2014-04-25 13:43 GMT+02:00 Thomas Paviot wrote:
> Dear all,
>
> In my opinion, this kind of discussion can only leads to misunderstandings
> and poor level discussions. Epy wrote that OCE code quality is better than
> OCCT without any proof. As an employee from the OpenCascade company, Andrey
> used his right of reply in a way which is not the most diplomatic one (the
> travis-ci.org integration with github was achieved by Denis Barbier, who
> should rather be thanked for all his work) and without many convincing
> arguments ("I'm pretty sure that..." cannot be considered as a technical or
> scientific fact).
>
> I suggest to consider this discussion as closed and move forward with
> constructive topics. Of course you're welcome Epy, Andrey, to keep going on
> contributing to this ml.

Thanks Thomas for your wise words. I would also like to say that the
best way to make an opinion is to try both OCCT and OCE. There is
little point in arguing that one is better than the other, users
decide which ones best fits their needs.

Denis

[jelle feringa]

That's an apt summary of the discussion indeed.

Though I sympathize with Andrey's last paragraph:

"Getting more general, let's recall that forking OCE had been caused by OCCT project being not publicly visible.

Now we are completely open to participation of open source community and will be happy to see OCE people contributing.
This way two projects can converge for the common benefit"

IMHO Andrey is correct to point out that the copyright / licensing situation has radically changed, and my percpetion is that OCCT is making steps towards to comply with the discpline of OS development ( bugtracker, git, there is a motivation of what the objectives are of 7.0.0 and I think some wise choices have been made ). 

Now, I'm curious to know:

   1) whether OCE has an "official" position as to how it correlated to the OCCT project ( i might not be aware )

   2) if not, would it be welcome to define this postion for once and for all? Its a recurring discussion, IMHO a "santioned" position to how the project correlate is important both for OCE, OCCT, and new developers looking to further develop CAD / CAM / PLM in an OS fashion, and to make an education choice whether to base development on OCE or OCCT. Denis' comment is interesting, albeit perhaps not the most practical ;)

-jelle

[D. Barbier]

Hello Jelle,

I do not understand your questions. You copied/pasted Andrey's last
paragraph, but then, you should ask: why don't OCE contributors
directly contribute to OCCT? This one is much more interesting,
because all contributors can explain their choice.

Denis

[jelle feringa]

Hi Denis,

I do not understand your questions.  You copied/pasted Andrey's last

paragraph, but then, you should ask: why don't OCE contributors
directly contribute to OCCT?  This one is much more interesting,
because all contributors can explain their choice.

Sorry, you're right.

I think it would be welcome to summerize how OCE relates to OCCT indeed, and am curious to hear if /how the license change should effect things.

You've had a outspoken and well motivated take on this, so I'm very interested to have your take on things.

Like Thomas wisely pointed out: Andrey's message wasn't exactly diplomatic, but the question at hand is relevant and interesting.

I'm also curious to know if you perceive a chance in culture at OCCT, one ( no git, no tracker no development blueprint ) that has seen quite a bit of chance.

How does that affect the OCE project and is OCE you warming up to the idea of developing closer ties to OCCT?

Andrey's message can be interpreted both as non-diplomatic as well as reaching out ;)

-jelle

PS: its not my intention for endless debate, nor polemic, I'm curious to hear your position

[D. Barbier]

OCE is driven by contributions from our users, this is why I am not
comfortable with your questions. You want OCCT documentation being
packaged? No problem, when someone provides a patch, it will happen.
Same for samples, tutorial, etc. There is no top-down management,
features are implemented only when someone decides to work on them.
My only commitments are:
* merge new OCCT releases quickly
* ensure that everything is free software
* help porters in building OCE on as many platforms as possible

I signed OpenCASCADE's CLA as promised, and have sent few patches to
them. The only reasons for not sending more patches are:
1) lack of time
2) lack of time, our patches must be adapted to OCCT master and tested
3) lack of time, our patches are often entangled and it is not
always trivial to apply a single one
4) lack of time, some patches require changes in configuration, and
I do not want to learn OCCT build system
5) lack of time, I have to check that I am the author of the
submitted patch, or that these changes can be considered trivial (like
fixing compiler warnings)

Do we want to have closer ties to OCCT? Honestly I have no idea. My
main goal is to have more contributions, and I am not sure that such a
move is useful for us. Yes, OCCT development is more open, and once
you sign their CLA, you are in an environment very similar to many
other free software projects. But this CLA is in my opinion a huge
mistake. There has been some heat on Debian mailing lists recently
about the choice of an init system, and upstart lost this battle
because of Canonical's CLA which were seen by many developers as a
no-go. I do not know if this is what prevents OCE contributors from
sending patches to OCCT; if I did not have promised to sign their CLA,
this would have been my opinion though.
On the other hand if there are people who are willing to forward
patches to OCCT bugtracker, I can spend time to explain how to do
that.

Denis

[jelle feringa]

Thanks, that's very insightful.

Denis

[Epy]

I agree with others; I'm not here to make a fuss. But I do want to make the following comments as I do not want some particular points to go undisputed.
 

Taking that OCE issue tracker contains 440 closed issues (after 3 years of existence), and most of those are related to tweaking build system, I estimate count of functional changes in the code as not more than 50. For comparison, in OCCT we have 40-80 commits to master branch per month, and half of them are bug fixes and improvements of functionality.

1 issue /= 1 commit and 1 commit /= 1 file changed and 1 commit /= 1 change/fix, this is comparing apples to oranges. I do 1 commit per individual fix mostly but others here do 1 commit for >10 fixes at once, and many pull requests contain multiple commits.

The real problem is that you do not know if something is fixed or broken in OCE.

This is classic FUD.

Regarding compiler warnings: building OCE 0.15 on Windows with Visual Studio, I get ~40 compiler warnings (depending on VC version and bitness).
OCCT builds with VC with 0 warnings since version 6.7.0.

GCC and Clang emit thousands of more warnings than MSVS as they are far more standards-compliant. Last time I compiled with -Weverything on Clang I got a 42.6 MiB text file of warnings. Point being, MSVS is not very standards-compliant and the figures above don't mean much to me except to show that Open CASCADE is focusing more on what platform the majority of customers use than strict standards compliance. Which is fine, I would too if I was doing this for money.

Another problem is that even if good fix is made in OCE but not submitted to OCCT, it has all chances to be lost with the next merge with official OCCT release.

I don't believe that Denis simply discards previous fixes when he merges each new OCCT release...

OCCT is more strict for accepting contributions but is more robust, since we control quality and non-regression of each integration

This is why I'll probably never even attempt to contribute to OCCT directly. Everyone here has been very welcoming when I present a particular item I want to fix. I've never been told that something can't be fixed. We have QC as well; changes are presented to everyone for at least 2 weeks to review before being merged. I try my best to review others' submissions and I know that at least Denis checks my work thoroughly.

*all that aside*

I still, after many years, do not have good grasp on FOSS licensing issues. My understanding here is that LGPL requires derivative works to also be LGPL. OCCT and OCE are both LGPL, can't OCCT simply take what it wants from OCE's codebase?

On Wednesday, April 23, 2014 8:50:15 AM UTC-7, Michele Fiorentino wrote:

[D. Barbier]

On 2014-04-25 17:50 GMT+02:00 Epy wrote:
> I agree with others; I'm not here to make a fuss.

Hmmm, really? ;-)

[...]

>> OCCT is more strict for accepting contributions but is more robust, since
>> we control quality and non-regression of each integration
>
> This is why I'll probably never even attempt to contribute to OCCT directly.
> Everyone here has been very welcoming when I present a particular item I
> want to fix. I've never been told that something can't be fixed. We have QC
> as well; changes are presented to everyone for at least 2 weeks to review
> before being merged. I try my best to review others' submissions and I know
> that at least Denis checks my work thoroughly.

[...]

In your first reply, you were stating that OCE was better than OCCT.
OpenCASCADE people could not read this without reacting, and moot
arguments have been thrown on both sides. It is undisputable that
OCCT development is much more active than OCE. Does it mean that OCE
is dead or useless? Of course not. We certainly have no incentive to
replace OCCT, we are a kind of external git branch (or tree) managed
by volunteer contributors. OCCT decided to have a strong control on
their repository (but they are very welcoming too when you
contribute), whereas we are very liberal. (Hey Windows porters,
please stop playing pingpong with CMAKE_ARCHIVE_OUTPUT_DIRECTORY,
thanks ;))
These are 2 antagonistic models, so a discussion about the best one is
going to generate a lot of heat. All, please do not take this thread
too seriously; in order to have a more realistic feeling about
OpenCASCADE, please consider contributing to their forums and/or
bugtrackers, you will see that they are very welcoming too.
Of course, you are entitled to dislike their cathedral model, as I do,
but we are no competitors, please be civil with OpenCASCADE developers
on this list, their contributions here are (almost ;)) always very valuable.

Denis

[Epy]

I was going to write a longer response, but I changed my mind.

All I'll say is that it doesn't seem proper for OCCT to complain about OCE in any way. All they have to do is subscribe to our GitHub and they basically get fixes for free. If they can't take them because they insist on owning IP rights, that's their problem, not ours.

[Epy]

What OCE has more w.r.t. OCCT is bindings with many additional tools, like Memcheck, Google Test, CPack, Travis-CI, etc.
However, does is work well?
I just clicked on green Travis-CI icon on main page of OCE in GitHub, and get to OCE page of Travis-CI
Here the build status is Ok (as I guess by its green color), but the log reads:

DRAWEXE is in /usr/bin, TKTopTest is in /usr/lib64/oce.
Somehow TKernel cannot dlopen libraries from there.

Fixes: ...

$ DRAWEXE
Draw[1]> Draw[2]> pload ALL
An exception was caught 0x7f7651614f63 : Draw_Failure: Could not open: TKTopTest; reason: libTKTopTest.so.8: cannot open shared object file: No such file or directory
** Exception ** 0x7f7651614f63 : Draw_Failure: Could not open: TKTopTest; reason: libTKTopTest.so.8: cannot open shared object file: No such file or directory

For me, it seems not really working...

This is a build of a proposed pull request that is being worked on currently. This is the last build of master: https://travis-ci.org/tpaviot/oce/builds/23096804

On Wednesday, April 23, 2014 8:50:15 AM UTC-7, Michele Fiorentino wrote:

[Michele Fiorentino]

Dear All,
I feel somehow sorry to have created such discussion, but I want to send my message to both communities: I am a kind of "midrange" user which is very interested to a free CAD kernel for research and maybe (future) business. I moved to oce when Opecascade get stucked for years with the same webpage and version, while oce team did well and stay active for many years.
We must credit them for such work and this is why I came back. Form this this discussion i finally got the basic points which are beyond all:

1) open repository
2) licensing

I firmly think that this division is a pity but also a richness, but I am also afraid that in future it will be harder and harder to merge the two...
What i am asking right now, also at the light of the new license status and opencascade activity to make it clear to the community in oce dev which are the  
main motivation behind and if possible the most important milestone changes which are not into opencascade.

I think this will be somehow stated in the very first page.

Regards to all
  

[D. Barbier]

On 2014-04-26 9:25 GMT+02:00 Michele Fiorentino wrote:
> Dear All,
> I feel somehow sorry to have created such discussion, but I want to send my
> message to both communities: I am a kind of "midrange" user which is very
> interested to a free CAD kernel for research and maybe (future) business. I
> moved to oce when Opecascade get stucked for years with the same webpage and
> version, while oce team did well and stay active for many years.
> We must credit them for such work and this is why I came back. Form this
> this discussion i finally got the basic points which are beyond all:
>
> 1) open repository
> 2) licensing

Hello,

I do not fully understand your points, but am pretty sure to disagree ;-)
In my mind, the only differences between OCE and OCCT are:
* OCE easily accepts contributions, whereas OCCT is much stricter
* OCCT provides commercial support
* OCCT has a much better knowledge of their code
Both provide full access to source code, test cases, bug trackers,
forum discussions, and share the same license.

> I firmly think that this division is a pity but also a richness,
> but I am also afraid that in future it will be harder and harder
> to merge the two...

Argument heard for years, I am still looking for evidence of this claim ;-)

> What i am asking right now, also at the light of the new license status and
> opencascade activity to make it clear to the community in oce dev which are
> the
> main motivation behind and if possible the most important milestone changes
> which are not into opencascade.
>
> I think this will be somehow stated in the very first page.

Okay, will think about it.

Denis

[Michele Fiorentino]

hi Denis,

well my point is not a point but 2 points with a line ;)
I try just to make clear about this double "cascade" thing at the end of your declarations: it's just 2 different groups of people?? (which as we see in this 3d, you know each other very well!)
as midrange, after this discussion, I am biased: which train may I take? legacy or freestyle?;) (if oce can be considered freestyle)
 Does legacy provide more robustness or just it avoid innovation? big question?? fire!

:)

[Andrey Betenev]

Hello Thomas,

Sorry for late reply..

On 25/04/2014 15:43, Thomas Paviot wrote:

Dear all,

In my opinion, this kind of discussion can only leads to misunderstandings and poor level discussions.

I believe the question asked by topic starter (what is the difference between OCE and OCCT) deserves more objective answer than that given by Epy.
I gave my opinion, which is clearly opposite to that is usually expressed here, and tried to be objective, givng facts and numbers where I have.

Epy wrote that OCE code quality is better than OCCT without any proof. As an employee from the OpenCascade company, Andrey used his right of reply in a way which is not the most diplomatic one (the travis-ci.org integration with github was achieved by Denis Barbier, who should rather be thanked for all his work)

Sorry if my answer was not sufficiently diplomatic, I am really trying to be polite and objective, and do not intend to offend anyone.
I estimate very high the work done by Denis for Travis-CI integration, and yet more the tremendous effort he does for maintaining OCE code and merging with OCCT releases.

and without many convincing arguments ("I'm pretty sure that..." cannot be considered as a technical or scientific fact).

Ok, the fact is: I have asked my colleague to build OCE 0.15 and OCCT 6.7.0 on Linux with the same compiler (GCC) options (-Wall), to see number of warnings.
His result was that OCE builds longer and yields more warnings...
I did not reported this however in my first answer because this kind of result should be cross-checked.
Hence I suggested that someone checks this independently -- if it is of interest, of course.

I suggest to consider this discussion as closed and move forward with constructive topics. Of course you're welcome Epy, Andrey, to keep going on contributing to this ml.

Ok, I just will answer on some relevant points arosen in this thread.

Best Regards,
Andrey

[Epy]

I'd like to see build times and warning outputs.

[Andrey Betenev]

Hello Epy,

On 25/04/2014 19:50, Epy wrote:

...

Another problem is that even if good fix is made in OCE but not submitted to OCCT, it has all chances to be lost with the next merge with official OCCT release.

I don't believe that Denis simply discards previous fixes when he merges each new OCCT release...

Denis does tremendous work merging releases, and to my knowledge he is able to merge intact all OCE fixes.

However, some changes get overriden when big pieces of code are changed in OCCT between releases.
It is not always possible to trace each fix to a new version of code.
It would be much safer if the changes were integrated in OCCT.

OCCT is more strict for accepting contributions but is more robust, since we control quality and non-regression of each integration

This is why I'll probably never even attempt to contribute to OCCT directly. Everyone here has been very welcoming when I present a particular item I want to fix. I've never been told that something can't be fixed. We have QC as well; changes are presented to everyone for at least 2 weeks to review before being merged. I try my best to review others' submissions and I know that at least Denis checks my work thoroughly.

*all that aside*

I still, after many years, do not have good grasp on FOSS licensing issues. My understanding here is that LGPL requires derivative works to also be LGPL. OCCT and OCE are both LGPL, can't OCCT simply take what it wants from OCE's codebase?

It is exactly IP rights isues that lead to requirement of signing CLA with every contributor.
The background is that OCCT is used in commercal projects made for industrial customers.
These projects are main driving force of OCCT development; OCCT would not exist without this.
In this context we need to have ability to provide customers OCCT-based solutions on specific conditions, not only LGPL.
Hence the need to have CLAs from contributors which give us this right.

Best Regards,
Andrey

P.S. I will check build logs on Linux during the next week.

[D. Barbier]

On 2014-04-27 5:39 GMT+02:00 Epy wrote:
> I'd like to see build times and warning outputs.

Hello,

I do not get your point, can you please elaborate?

Denis

[Andrey Betenev]

Hello Denis,

Thank you for understanding our position and giving a nice summary.

I would like to comment on your statement regarding cathedral model of
development for OCCT.
Here I cannot completely agree.
Well, it is true we are trying to plan OCCT development in advance and
to follow the plan...
The fact is, however, that most of changes in OCCT are caused by
specific needs of different projects, rather than being planned.
This often leads to suboptimal solutions such as alternative
implementations of similar functionality.
We are trying to minimize that, but till now our cathedral has too much
of the bazaar... :)

Andrey

[Andrey Betenev]

Hello Michele,

On 26.04.2014 14:11, Michele Fiorentino wrote:
> hi Denis,
>
> well my point is not a point but 2 points with a line ;)
> I try just to make clear about this double "cascade" thing at the end
> of your declarations: it's just 2 different groups of people?? (which
> as we see in this 3d, you know each other very well!)
> as midrange, after this discussion, I am biased: which train may I
> take? legacy or freestyle?;) (if oce can be considered freestyle)
> Does legacy provide more robustness or just it avoid innovation? big
> question?? fire!

I believe no one here wants to avoid innovation, it is always wanted. :)

In OCCT we are likely more strict because we have much heavier
non-regresssion testing process, including customer cases.
This is a problem sometimes, we have some very nice and promising
improvements that remain in the queue for ages due to regressions...
However, this situation is rare, and most of contributions go smoothly
as soon as they are justified (review is required for each fix, and test
case is highly desirable when it makes sense).
In any case, as Denis correctly pointed out, you have to try to see the
difference.

Andrey

[Epy]

Hi Denis,

He made the claim "His result was that OCE builds longer and yields more warnings..."

I'd like to know if this is true. I'd be somewhat embarrassed if OCE turned out to have more warnings than OCCT with all the time I've put into fixing compiler warnings lately.

-Jake

[D. Barbier]

On 2014-05-01 18:41 GMT+02:00 Epy wrote:
> Hi Denis,
>
> He made the claim "His result was that OCE builds longer and yields more
> warnings..."
>
> I'd like to know if this is true. I'd be somewhat embarrassed if OCE turned
> out to have more warnings than OCCT with all the time I've put into fixing
> compiler warnings lately.

Hello Epy,

Your fixes had been merged into OCE 0.14, based on OCCT 6.6.0 released
one year ago. According to git logs, it is pretty clear that OCCT
developers began fixing all Windows level 4 compiler warnings in July
2013, and they claim that OCCT 6.7.0 builds without warnings on
Windows.

In OCE, we started fixing these compiler warnings 3 years ago. Each
new OCCT release came with its load of new source code with new
compiler warnings, which we had to fix again and again. That was
definitely not fun, so to tell the truth, I do not care whether OCE
has 10 compiler warnings more than OCCT now. If this is true, I won't
even get embarrassed, because I know the amount of work we did to fix
those warnings, and our users thanked us for this service.
The most important point is that we will no longer have to fix lots of
new compiler warnings at each release.

This is the same for the other claim: OCCT builds faster than OCE. It
may be true; the main difference which comes to my mind is header
location; we decided to drop the top-level inc/ directory, and have
thus to pass many -I flags. Even if this is true, you have to
remember that when Thomas replaced OCCT build system by CMake, our
build system was much faster. So when OCC developers eventually adopt
CMake, I am very happy, even if they claim that their one is now
superior to ours.
And if you want to rebut this claim, simply enable precompiled headers ;-)

Denis

[Epy]

Andrey,

I am willing to sign the CLA *if* someone at OCCT volunteers to watch my commit log on GitHub and make the bug reports / changes for OCCT as needed. I'm not interested in working directly on both projects, but this way OCCT would be free to take note of any fixes I make and take what they want. What would be best is if OCCT staff got involved on GitHub to help us come up with agreeable fixes so that codes can match and Denis doesn't have to do more work than necessary. Basically you're saying "get involved on our bugtracker so both projects benefit" and I'm saying "get involved on our GitHub so both projects can benefit." I prefer my option because it's much easier for me to just start fixing things here. I can change files quickly without having to file several bug reports.

-Jake

[Thomas Paviot]

Hi Jake,

This sounds as a good argument and a reasonable proposal. Indeed I don't think is up to you, Denis or any of us at OCE to retrieve commits, select them, package and send the patch to OCC and take care of its integration into their repository. We can help, but this is a huge task that requires time, a good knowledge of occt workflows, release plan, a knowledge of mantis etc. And without being certain that the patch will actually be merged in a reasonable time. Then this work has IMHO to be managed by OCCT guys the way they want it to be done, according to their workflow, (private) bug tracker and (private) git repository which are quite different than what we've been using OCE.

That said, I definitely agree with your "get involved on our github so both projects can benefit". And it's much easier since everything is open at OCE and integrated in a consistent github toolsuite.

You're welcome here OCCT people, we're waiting for your volunteer(s) to raise his(their) hand(s)!

Thomas

[Andrey Betenev]

Hello Jake,

On 01.05.2014 20:41, Epy wrote:
> Hi Denis,
>
> He made the claim "His result was that OCE builds longer and yields
> more warnings..."
>
> I'd like to know if this is true. I'd be somewhat embarrassed if OCE
> turned out to have more warnings than OCCT with all the time I've put
> into fixing compiler warnings lately.
>
> -Jake

Ok, here you are: this is a summary of results of my experiments
building OCCT 6.7.0, 6.7.1, and OCE-0.15 on two Linux stations (sorry it
took longer than expected!).

On Debian 6.0 x64 with gcc 4.4.5 (building by plain makefiles):
OCCT 6.7.0: builds in 55 min, yields 220 warnings
OCCT 6.7.1: builds in 57 min, yields 20 warnings
OCE 0.15: builds in 79 min, yields 121 warning

On Ubuntu 13.04 with gcc 4.7 (building by Code::Blocks):
OCCT 6.7.0: builds in 65 min, yields 552 warnings
OCCT 6.7.1: builds in 64 min, yields 130 warnings
OCE 0.15: builds in 82 min, yields 89 warnings

I used CMake with all-default settings, except that for OCE I have
enabled DRAW and TCL, and added option -Wall explicitly (it is default
for OCCT).
All builds were made with only one 3rd-party library enabled (Freeimage).

The logs can be found in the attached archive; I have removed progress
marks like "[15%] Building ...file.o" and HTML mark-up to reduce logs size.
The number of warnings above is the one obtained by "grep warning:
<log-file> | sort | uniq | wc".

As we can see (no surprise), the number of warnings is very dependent on
the compiler.
Thus it does not make much sense to argue on their numbers, we shall
better concentrate on how to get rid of them.

The problem here is that while you are removing some warnings, another
developers work hard introducing new ones ;)
That is why we have focused on establishing an integration process in
which appearance of new compiler warnings is controlled in every
integration.
This has been set up a year ago, then we have addressed Windows (VC++)
warnings, dropping them to zero.
Now we have mostly sorted out GCC warnings; the few remaining are
registered in bug tracker and are waiting for more in-depth analysis.
(This is for GCC 4.4.5 which we use by the moment; as we see from the
attached logs, GCC 4.7 reports many new ones).
CLang warnings started to be controlled last month, and we should have
many of them fixed in 6.7.1.

Naturally we would appreciate help of OCE team in fixing the remaining ones.

Andrey

[Andrey Betenev]

Hello Jake,

I encourage you to sign CLA even if you are not going to contribute to OCCT directly -- this will facilitate possible integration of your changes in any case.

Naturally I cannot promise that someone here will watch your or anyone's else commits and fetch them.
However, I am looking at OCE from time to time, and perhaps will want to take something one day.
Warnings fixes are the first candidates.

I guess submitting OCE fixes to OCCT would be mostly helpful for Denis to minimize his work on merging two versions.

Andrey