.cpp and header files jme3-bullet-native

These header files auto generate in NetbBeans,

jmonkeyengine/jme3-bullet-native/src/native/cpp at master · jMonkeyEngine/jmonkeyengine · GitHub

Is there a reason they are included in the repository and not deleted after doing a build?

1 Like

They are source files not files from a build. It’s the JNI bridge to bullet
header files might be generated yes… but they should not be deleted.

1 Like

I think his point is that they are generated and yet also checked into GIT… which means they could look changed all the time.

I’m a big proponent for NOT checking in files that are generated by the build anyway… release issues aside (packaging a release is a separate thing).

1 Like

Exactly what Paul said.

Once they are copied into jar they are not needed in the source right?

Well tbh I don’t know.
I guess they are not, but I never looked into this…

I have tested the delete of all .h header files before any build (win7 desktop Netbeans and command prompt) with the exception of leaving these that do not update:

They are generated new in the src/native/cpp folder and copied into the build/lib SnapShot-sources jar with new timestamps. If after that first build/copy you just leave the header files alone in the src/native/cpp folder, they are not copied. The timestamp doesn’t change in build/lib SnapShot-sources jar.

What would be a solid way to test this in game?

After picking at this some more I find that building from the subproject node doesn’t cause the header file to be compiled.

Timestamp only changes if run build from the project root node.

I see whats going on.

Its bullet.

Can someone with more knowledge about the native stuff answer, please? @Empire_Phoenix maybe. Or @normen if you’re around?

Well I know that for bullet some headers are generated, that then match the actual definiton on how they should look in java code. These probably should not be checked in, as they are only required when nativly compiling bullet, to create the jni stuff on the c side. In my opinion they should be removed and ignored. (That is, if nothing breaks of course)

1 Like

They have only been auto-generated since gradle, thats the reason they’re in the repo. As it seems that method doesn’t seem to work too well either so I don’t know if they should be taken out.

Creating header files isn’t exactly a build step, I guess its in there for convenience. Imo the files should stay and the generation taken out.

Then maybe the generation should be kept as a separated gradle task that one could run manually and commit the generated files, if we need it, and stop running it on each build.