search

bytedeco / javacpp-presets

The missing Java distribution of native C++ libraries
Other
2.63k stars 731 forks source link

Parser question, requires additional parentheses in order to parse a file #1231

Open ds58 opened 1 year ago

ds58 commented 1 year ago

I am working on creating presets for GTSAM. I'm running into a parsing issue with this return statement here, however: https://github.com/borglab/gtsam/blob/develop/gtsam/base/Manifold.h#L131

[ERROR] Failed to execute goal org.bytedeco:javacpp:1.5.8-SNAPSHOT:parse (javacpp-parser) on project gtsam: Failed to execute JavaCPP Builder: /home/d/projects/javacpp-presets-gtsam/gtsam/cppbuild/linux-x86_64/include/gtsam/base/Manifold.h:134:Could not parse declaration at '.'

If I modify this return statement to include additional parentheses, it will parse correctly. Is there anything I may have overlooked in order to avoid this? Or, should I look at modifying the headers in order to please the parser?

Original 

  return v0.norm() < tol && traits<T>::Equals(b,c,tol);

Modified

  return (v0.norm() < tol) && (traits<T>::Equals(b,c,tol));
saudet commented 1 year ago

That's most likely a bug in the parser, where it's trying to match the first < with a > it doesn't find...

ds58 commented 1 year ago

I think the solution for my case would just be to create patch files that address any minor parsing issues like this. During the build process, the patch files will get applied just after downloading the src.

saudet commented 1 year ago

Yes, the easiest way to work around this kind of small issue is with a patch at build time. That's what happens in the cppbuild.sh file of many presets for a variety of small and not-so-small issues.

In this case, we can probably fix this one in particular and I'll eventually get around to it, but it's not always possible to disambiguate C++ syntax without the whole context. For example, if we had return norm < tol instead, unless we use a full C++ compiler like Clang, see issue https://github.com/bytedeco/javacpp/issues/51, it's not possible to know whether "norm" is a type or a value. If we assume it's a type, we get a syntax error, if we assume it's a value, we get a syntax error for return norm < tol >, so in the case where we don't have access to that information, we need to hack it to allow both syntaxes, but it gets really complicated, and we might as well just use a full C++ compiler, for other reasons too.