OpenCASCADE 7.4.0 #845
OpenCASCADE 7.4.0 #845
Conversation
|
As you can tell from the diff, OpenCASCADE is massive. FWIW: it looks like CI is running even though this is a draft? |
|
Hum, this is annoying. Why did they start doing that? Anyway, one thing that works for sure is temporarily deleting the .appveyor.yml and .travis.yml files. |
|
Closing it for now since maybe that will stop triggering the builds. Got this error:
I know how to fix this, but I was following the Create New Pretests documentation and it said:
Should that be updated, or did I hit a special case where it turned out to be crucial? |
|
Currently failing here: Looking at that |
|
That just means the JAR file doesn't exist. Make sure to try to build it locally first. It's much easier to debug that way. |
|
If you don't mind about JPMS, yes, we can erase all that, that's not a problem. It's not going to help you create the missing JAR file though. |
|
Yep, I'm working locally. I took the -- note: |
|
|
|
.... except apparently we're not looking at the same thing, because closed draft PRs don't see new commits being pushed to the source branch apparently? I swear I felt like I understood GitHub 5 years ago and now I do not. |
|
Reopening it made the extra commit show up, but also re-triggered CI. |
|
Let's see if closing it again makes Jenkins stop doing work. |
|
Woo, that did it! Sorry for the e-mail notification spam -- see above for where I'm stuck at. |
Like I said, just delete As for why it's not producing a JAR file, you'll need to have some content or it will keep skipping creating one as shown in your log above: |
|
I've temporarily deleted those two files, disabling CI. What's supposed to be in that jar? Just the .so's, or .so's + the generated InfoMapper class file? I'd expect the latter, and it to not be empty because of that. Do I edit the toplevel pom.xml, the module pom.xml, or the platform pom.xml? I assume it's the module pom.xml, but the Create New Presets wiki page doesn't seem to suggest I put anything in there beyond what's already in this PR. |
| * limitations under the License. | ||
| */ | ||
|
|
||
| package org.bytedeco.ale.presets; |
There was a problem hiding this comment.
You'll need to place your class in this package here:
[INFO] --- javacpp:1.5.3-SNAPSHOT:parse (javacpp-parser) @ opencascade ---
[WARNING] No classes found in package org.bytedeco.opencascade.presets
[INFO] Detected platform "linux-x86_64"
[INFO] Building for platform "linux-x86_64"
|
Progress! Thanks for pointing out that error. I've fixed that and got further. Current error: Here's the header file that breaks: // Copyright (c) 1998-1999 Matra Datavision
// Copyright (c) 1999-2014 OPEN CASCADE SAS
//
// This file is part of Open CASCADE Technology software library.
//
// This library is free software; you can redistribute it and/or modify it under
// the terms of the GNU Lesser General Public License version 2.1 as published
// by the Free Software Foundation, with special exception defined in the file
// OCCT_LGPL_EXCEPTION.txt. Consult the file LICENSE_LGPL_21.txt included in OCCT
// distribution for complete text of the license and disclaimer of any warranty.
//
// Alternatively, this file may be used under the terms of Open CASCADE
// commercial license or contractual agreement.
#ifndef _Standard_Persistent_HeaderFile
#define _Standard_Persistent_HeaderFile
#include <Standard_Type.hxx>
//! Root of "persistent" classes, a legacy support of
//! object oriented databases, now outdated.
class Standard_Persistent : public Standard_Transient
{
public:
DEFINE_STANDARD_ALLOC
Standard_Persistent() : _typenum(0), _refnum(0) {}
DEFINE_STANDARD_RTTIEXT(Standard_Persistent,Standard_Transient)
Standard_Integer& TypeNum() { return _typenum; }
private:
Standard_Integer _typenum;
Standard_Integer _refnum;
friend class Storage_Schema;
};
#endif // _Standard_Persistent_HeaderFileI'll try taking that out and moving on but I figured that would be useful information already :) Thank you for your help so far! |
|
Thanks! That documentation is extremely well written: it quickly got me to exactly the two cases I've needed to cover so far. Is there a way to continue on error so that I get all of the failures in one go instead of having to do a full |
|
We can skip some steps like "mvn -Djavacpp.cppbuild.skip ..." to speed things up, but the parser isn't that great, no. |
|
OK, new place I'm stuck: Relevant section of the header file: #ifndef NCollection_BaseList_HeaderFile
#define NCollection_BaseList_HeaderFile
#include <Standard_NoSuchObject.hxx>
#include <NCollection_DefineAlloc.hxx>
#include <NCollection_ListNode.hxx>
typedef void (* NCollection_DelListNode)
(NCollection_ListNode*, Handle(NCollection_BaseAllocator)& theAl);
// ********************************************************** BaseList class
class NCollection_BaseList
{
public:
//! Memory allocation
DEFINE_STANDARD_ALLOC
DEFINE_NCOLLECTION_ALLOC
public:
class Iterator // 💥 line 44 where the error happens
{
public:
// ******** Empty constructor
Iterator (void) :
myCurrent (NULL),
myPrevious(NULL) {}
// ******** Constructor with initialisationI assumed the error was the (previously undefined) I'll continue reading that document and define more things from the headers included by that header to try and make progress in the mean while :) |
|
Are includes literally "included" in-line? E.g. if I see a failure on line 44 and I start scanning for the stuff in front of it, is it possible the problem is actually in an included file? I ask because after walking the recursively included headers, I'm seeing two new custom macros |
|
No, they are not actually included as explained in this section: |
|
Hm, OK: would you expect to see that Given the huge number of header files I'm likely to do an actual topological sort with an ad-hoc parser rather than a manual one :-) |
|
Listing the header files isn't what takes most of the time. If you feel that even this small task is going to take long, you should probably consider helping out with this first: bytedeco/javacpp#51 |
|
I'm just trying to make a little progress at a time. Since I've never done this before, it's hard to know which parts will be tricky. It makes sense that normally that part would be easy, but this thing has thousands of header files! Should I interpret your comment to mean seeing |
|
Yes, we need to start by including the header files that contain those macros first. |
|
Always compiling is a pain in the ass and takes about 40min. If build once, I did a shortcut to speed-up:
This way the result gets copied everytime and there is no need to recompile. One thought on I did a small test with helloworld-2.0 and exactly this nested class combination and it worked. Might worth to give it a try? |
|
Update on that. |
|
Ok, I broke the whole library into frameworks. Started with framework Foundation as this is the base for everything else. I included this in opencascade.java via inherit and moved everything foundation related to presets/frameworks/Foundation.java. Foundation has 2 Toolkits. TKernel and TKMath which have several modules. If I get it working I'm thinking about a more granular structure... Everything works fine, except when compiling. cmake installed opencascade headers into include/opencascade as usual but clang can't find them: Is there a way to tell the compiler the exact directory for the required includes? My current solution would be to tell cmake to output to include instead of include/opencascade. BTW I'm on macOS. |
|
When the files are in a "opencascade" subdirectory of the "include" directory, including "opencascade/Standard_Transient.hxx" instead of just "Standard_Transient.hxx" should work. |
|
Sorry my quoted error message is confusing. Here is a whole error: I can't change Using -DINSTALL_DIR_INCLUDE=include does the trick by now. I had to exclude several headers from Foundation @Property include as they are throwing errors when compiling and they don't hold any neccessary data structures for me, just internal library stuff that doesn't need to be accessible. Everything compiles fine now but the resulting Here is my branch: |
|
It sounds like we need to add more include directories. Those can be added to the list here: |
|
Sorry, I've been meaning to add an update to this. I wrote a dinky little tool that takes an I expect that it won't be super useful generally, but at the same time I won't be the last person to bind a library with more than a few header files, so I'll put it out there regardless. Re: OpenCASCADE itself: a big problem I've ran into is the As a consequence I don't think I can land this by myself, so I'm very happy to see @mmaenz step in :) |
|
Heads up, I was mistaken about how memory management works, they since then have come up with a better scheme, see tpaviot/pythonocc-core#220. |
|
SWIG was my first try to use occ with java and I modified tpaviot's generator wrapper. It is a python script which parses most of occ's headers and groups them into modules. It then generates the .i files required for SWIG. I was really disappointed about SWIG because it produces a flat java package and strange exceptions and after a long while i switched to javacpp. I emailed tpaviot for help but no response. At least I used his python script to sort all headers by framework -> toolkit -> Module. His script produces nice collections of related headers like NCollection_module.hxx with all relevant headers inside. Sadly (I'm not sure all at) I read somewhere that javacpp can't follow #include directives so I'm going to modify his script to output (as text to copy) all relevant headers for each module. The Handle is quite tricky. As far as I understand the sources, there is a base class I'm not sure but I wouldn't care about internal memory management of occ. It's kept in the library and not on the java side. We need these 3 as classes in Java for use? |
If they are part of the public API, yes, but if they are not meant to be called by end users, no. |
|
In my fork is a structure directory with information about the library and relevant header files sorted by modules. I got reply from Agostino de Marco who had build jCAE in the past and worked with Thomas Paviot. He said he once bought the swig interface files from OpenCascade and ported them to 7.3.0. He said it was a pain and took real effort. However he is willing to contribute again. The newer versions of swig files are really pricy. @lvh If you need an urgent running occ in java, I managed to get it done with opencascade 7.3.0 They didn't port the whole library, only the most needed headers to get most of the things working. I'm going to do the same now for javacpp and, if needed, more specific things on demand. May it be possible to move the discussion out of the PR? If it get's closed, a lot of information will get lost? |
Yes, that's how it should be done.
This thread won't get deleted when the PR is closed. If you get something up and running and you open another PR, we can just reference this thread "for more information". |
|
BTW, if Open CASCADE has a C API, even if it's limited, that's usually straightforward to map, so it could provide a good initial step and we would get something minimally usable right away. |
|
Unfortunately they don't :-( I'll start by figuring out how to do this with pythonocc so at least I know what subset of APIs I need and how they're supposed to work. But this is a side project, so nobody should hold their breath :) |
Hello, I confirm I'd like to help out with this preset. I just have to figure out how to start off working with javacpp. |
|
@agodemar Please start here: https://github.com/bytedeco/javacpp/wiki/Mapping-Recipes |
|
@lvh @mmaenz @saudet |
As #844, but as a draft this time.