gluegen - examples needed

doofx wrote

warning: reference gluegen classpath not found

Ant doesn't understand gluegen.classpath because you missed that:
https://github.com/sgothel/gluegen/blob/master/make/build-test.xml#L67

Yee I have a similar newbee situation :) - let me know if this needs to be it's own topic and I'll create one!

I am just getting started with gluegen and basically need to start with a "hello world" type of build.  I have built gluegen and jogl, and it all works properly and the JOGL test suite is successful.

What I woudl love is for a simple gluegen built class a simple complete script or gnu make makefile (not Ant) which isn't factored in a convoluted hard to untangle blob of hard to trace dependencies for a simple complete C+java application.

Basically A "C" file with a simple method or methods in it like void printString(char *string) { printf(string); } and the associated .h .cfg (etc) files required for the build.

So when the simple script is run, gluegen is applied, it generates output (there are samples in the gluegen manual for part of this but only geenrating some of what is needed)

And it's output is then combined with and any ancilary code needed to create a complete loadable DLL  with all the proper export declarations and or export symbol tables, bind it with whatever libraries might be needed, and a simple java main() class that will load the built DLL and classes and properly call the method.

Ideally for both GCC and/or Microsoft (visual C) command line compilers.

An extended "complete" version would have a method for each data type supported by gluegen such as the ones well exemplified in the gluegen manual.  That part seems good, it's putting the whole thing together in a non-ant build to start working on a real C+java app is my issue.

Thanks!

Hi

You should fill a bug report about your request for enhancement even though it concerns the documentation.

Edit.: This example should be enough:
http://jogamp.org/gluegen/doc/manual/#SecSimplest

not being a committing developer or tester - how should I go about this?
thanks.

On 7/20/2014 2:34 AM, gouessej [via jogamp] wrote:

Hi

You should fill a bug report about your request for enhancement even though it concerns the documentation.

Julien Gouesse | Personal blog | Website | Follow me on Identi.ca

---

If you reply to this email, your message will be added to the discussion below:

http://forum.jogamp.org/gluegen-examples-needed-tp4031123p4032592.html

To unsubscribe from gluegen - examples needed, click here.
NAML

Ok - I tried executing the script in jogamp/gluegen/doc/manual/example1

right definitely a documentation bug on top of needing some improvement.

To get it to run on a mingw shell on a windows machine:

#!/bin/ksh doesn't exist in the mingw install so it wont run from mingw bash shell (I switched it to #!/bin/bash)

- The classpath wasn't in quotes.
- The path to the antlr jar file was wrong.
- The GlueGen package path has changed. (it's now com.jogamp.gluegen instead of com.sun.gluegen)

I also set it to look at JAVA_HOME to find java as it wasn't in my base path. *(I need to switch between 32 and 64 bit at times)

Once I fixed the above the gluegen I built ran and output code properly when running the sample script.

*****

The next step is to have the generated code compile and link into a DLL that will load and run in the generated class.

If a simple "Hello World" test app/examples and a script for them to build and run was part of the rather extensive test suite this lack of documentation sync would be easy to maintain or at least detect as the build-test would have failed.

I would automate the example script generation with a string substitutor so the package name and other globals came from a main build wide setting when the example scripts are output.

I can help if needed to work on it, but at this point I'm likely best as a first encounter tester ;^>

Peter K.

On 7/20/2014 2:34 AM, gouessej [via jogamp] wrote:

Hi

You should fill a bug report about your request for enhancement even though it concerns the documentation.

Julien Gouesse | Personal blog | Website | Follow me on Identi.ca

---

If you reply to this email, your message will be added to the discussion below:

http://forum.jogamp.org/gluegen-examples-needed-tp4031123p4032592.html

To unsubscribe from gluegen - examples needed, click here.
NAML

peterk wrote

not being a committing developer or tester - how should I go about this?

If you go to https://jogamp.org/bugzilla/ and enter a new bug, it'll prompt you to create an account first (I think it emails you an account confirmation automatically, so it doesn't require our intervention).

Sent from my phone.


-------- Original message --------
From: "Wade Walker [via jogamp]" <[hidden email]>
Date: 07/20/2014 14:30 (GMT-05:00)
To: peterk <[hidden email]>
Subject: Re: gluegen - examples needed


).

peterk wrote

not being a committing developer or tester - how should I go about this?

If you go to https://jogamp.org/bugzilla/ and enter a new bug, it'll prompt you to create an account first (I think it emails you an account confirmation automatically, so it doesn't require our intervention).

---

On 07/20/2014 03:09 AM, peterk [via jogamp] wrote:
<snip/>

> *And* it's output is then combined with and any ancilary code needed to create
> a complete loadable DLL  with all the proper export declarations and or export
> symbol tables, bind it with whatever libraries might be needed, and a simple
> java main() class that will load the built DLL and classes and properly call
> the method.
>
<snip/>

> An extended "complete" version would have a method for each data type
> supported by gluegen such as the ones well exemplified in the gluegen manual.
>  That part seems good, it's putting the whole thing together in a non-ant
> build to start working on a real C+java app is my issue.

GlueGen unit tests:
  <gluegen/src/junit/com/jogamp/gluegen/test/junit/generation/>
  <gluegen/src/junit/com/jogamp/gluegen/test/junit/structgen/>

contain thorough tests of:
  - generating the java and native 'glue' based on C header files
  - the C 'tool' native code
  - testing the code

It uses our ant build facility, hence you would need
to create your own 'scripted' or Makefile based version!

~Sven

>
> Thanks!
>

FYI - I just got a simple DLL plus Java main building and running like so many "start here" situations once people get beyond the initial hump they forget about it and move on which is why in so many OSS projects how to install and get the initial environment up is often the most thinly or inconveniently documented and most frustrating part of the experience.

Once I got the generator script working then I managed to figure out that you need to use the "jni.h" to compile it and it comes for the jdk distribution. The export flags etc are defined in there and for the current platform it is present in the ${JAVA_HOME}/include area and you also have to add the specific appropriate platform dependent directory, in my case win32 into the include path.

Also I notice that with JOGL a copy of jni.h is included in the distribution.  Knowing whether that is a special customized version or just a convenient copy is not in the docs either.

I was then able to build it all and run it.  But I will say something that would take an hour or so with a "hello world" script took me a day or so of annoyance and because of the inestimable nature of sussing out the unknown almost caused me to fall back to "SWIG" at the request of the project manager.  As a first encounter with a library not a good way to get it adopted :)

FYI though it was mentioned on StackOverflow that MSVC was not supported by gluegen I was able to build the DLL with both GCC and VC10 properly.  Whether all the data types are supported on both compilers not I'm sure but the generated code seems generic enough that some simple header munging  should make it relatively easy to support both.

PK

Maybe you could share a description of what you did so the documentation can be improved.

I posted the sample script bugs to bugzilla.

Like many of these "get the first build going" it was actually almost brain dead simple - once you know it.  The thing is when you don't know it it can be hard to guess and find information and thus frustrating.

1st I got the generator script in the doc/manual/expample1/gen.sh to work by fixing it as stated above.

Then I tried to compile the code by putting the source files into a basic build script that builds a DLL.

I searched my machine for instances of "jni.h" because I know if you were building it for jogl it had to be there somewhere.  I found two copies one in the jdk install and one in the jogl/make/stub_jncludes/i/jni.h  (I do not know if the jogl one has special customizations or if it is just a convenience copy)

jni.h includes a machine dependency include jni_md.h of which there are instances for various platforms in separate folders under the stub_includes/jni folder and one for the current platform in the jdk install.

I added an include path for my build to the one in JAVA_HOME for jni.h and added another include path for the "win32" folder under that for the platform include.

At this point the DLL built and linked properly, I was able to do so both with MSVC10 and GCC as my build script can specify either.

I was able to run a small java app that loaded the DLL the build created using System.load(dllpath), and called the sample method in the DLL.

It required the addition of no other libraries than the standard platform system libs, though I did have the gluegen_rt.dll in the run directory as well as the gluegen_rt.jar so it might have loaded that.

PK

Thank you for your detailed observations which might help to improve the documentation. I really hope that your suggestions will lead to less frustration for the next GlueGen adopters (especially concerning jni.h).

However, keep in mind that "bashing" OSS / free software isn't the best way of getting any help. We do what we can with the mean that we have. I remind you that OSS / free software libraries don't have a monopoly on bad documentation and when you don't have access to the source code, in my humble opinion it is even worse, it gives you no chance to understand what you try to use.

Moreover, building DLLs with MS Visual Studio is a very bad idea because an end user might have to run a MSVCR installer in order to make your program work if its DLLs aren't found and relying as little as possible on proprietary softwares when building a (proprietary or not) library is both sane and wholesome. You're not the only one to use MS Visual Studio, a former colleague sent a patch to build JOGL with it and it has never been included which is fully intentional even though I was a bit skeptical at that time and I think that maintaining a single code path for GCC is more useful than maintaining 2 code paths including one whose usefulness is debatable and which won't be used to produce the "official" builds.

Finally, a good documentation helps but in my humble opinion, there is an increasing tendency of laziness in the wannabe programmers, there are a lot of people who don't really want to understand what they are doing, they just want to obtain results by asking superficial questions. It's probably not your case as you spent some time in explaining what was "wrong" but some tools aren't used a lot even with an excellent step by step documentation mostly because understanding them takes too much time for those people who want a result right now, immediately, with no intellectual effort. For example, creating a Minecraft-like game with ArdorCraft is very easy, there are already several runnable examples, it should be motivating except for those who want to create a game in one week. Therefore, we won't discourage any developer from using SWIG instead of GlueGen even with the best documentation of the world.

Sent from my phone.


-------- Original message --------
From: "gouessej [via jogamp]" <[hidden email]>
Date: 07/22/2014 04:38 (GMT-05:00)
To: peterk <[hidden email]>
Subject: Re: gluegen - examples needed


Thank you for your detailed observations which might help to improve the documentation. I really hope that your suggestions will lead to less frustration for the next GlueGen adopters (especially concerning jni.h).

However, keep in mind that "bashing" OSS / free software isn't the best way of getting any help. We do what we can with the mean that we have. I remind you that OSS / free software libraries don't have a monopoly on bad documentation and when you don't have access to the source code, in my humble opinion it is even worse, it gives you no chance to understand what you try to use.

Moreover, building DLLs with MS Visual Studio is a very bad idea because an end user might have to run a MSVCR installer in order to make your program work if its DLLs aren't found and relying as little as possible on proprietary softwares when building a (proprietary or not) library is both sane and wholesome. You're not the only one to use MS Visual Studio, a former colleague sent a patch to build JOGL with it and it has never been included which is fully intentional even though I was a bit skeptical at that time and I think that maintaining a single code path for GCC is more useful than maintaining 2 code paths including one whose usefulness is debatable and which won't be used to produce the "official" builds.

Finally, a good documentation helps but in my humble opinion, there is an increasing tendency of laziness in the wannabe programmers, there are a lot of people who don't really want to understand what they are doing, they just want to obtain results by asking superficial questions. It's probably not your case as you spent some time in explaining what was "wrong" but some tools aren't used a lot even with an excellent step by step documentation mostly because understanding them takes too much time for those people who want a result right now, immediately, with no intellectual effort. For example, creating a Minecraft-like game with ArdorCraft is very easy, there are already several runnable examples, it should be motivating except for those who want to create a game in one week. Therefore, we won't discourage any developer from using SWIG instead of GlueGen even with the best documentation of the world.

---

Ok. Free software is about freedom after all, feel free to use MS VS if you want, I won't spend any time in supporting it as this is what I want.

Personally I don't find writing documentation annoying, it's a matter of taste. At first, it's useful for me, it allows me to resume a project even after a very long pause, I don't waste a lot of time in understanding what I did, I know what has been done and what I have to do. When I write some documentation, it forces me to think about how to explain what I do, it forces me to clarify some aspects so that I have a chance in succeeding in explaining my stuff. Secondly, it's useful for others even though I don't use silly names for my variables. Anyway I understand that some developers find this kind of task boring, especially when documenting the work of someone else.

Oh my ... I have just read your bug report and I admit that there were some really wrong things :s
I never use GlueGen under Windows. I run it under Linux a few days ago and it worked without any trouble, I used the Ant script within Eclipse Kepler. I stopped using the other scripts not based on Ant since we switched to JOGL 2 and it seems that I'm not alone in this case.

Not sure whether this should be on this thread but being an opinionated
idealist myself do rant a bit :)

On MSVC - I agree in many ways with what you say, but often especially
with low level items I find the need is primarily for dynamic
adaptability to various development contexts.

In my current case is I'm arguing to get a java graphics engine moved
away from AWT toward "modern OpenGL" for obvious reasons, but the cost
of a re-write to saleable usability means it won't happen unless a
customer pays for it and is willing to wait.  So the need is to
incrementally add some stuff to a bunch of demos and slowly push it
forward.  For this module I was given a typicaly overly short deadline
to hack in some features in to the AWT engine to support some windows 8
multitouch drivers and some other native features.

Of course I want to start with, and learn a system that might be the
best for long term rather than clutter my brain with needless dead end
junk I have to cram in there for the deadlines.

But in this particualr case ( and most cases are by nature particular )
we have an existing build system ( I might mention I find ant an insane
abomination - XML is not a script - and we use a ruby based build system
I may put into OSS ), also the C++ part uses VC10 mainly because other
staff and clients know how to use the "visual debugger" in the
VisualStudio IDE and use MSC in their build settings which are global
for the whole project.  Also the cut-n-paste windows 8 code and samples
out there on-line are usually compilable on MSC so integrating in the
hacks for the demo will be easier.

Likewise on the MAC we are using the objective C/C++ variant of GCC used
by apple for iOS and MacOS compiles etc.  And then of course there is
Windows-Phone which is a whole other can of worms that MUST use MSC :)

Another nasty bit is often whatever is used for a demo gets passed on to
others to extend and they end up using the same packages just because
that is what they start with.  And a demo often gets extended for a
paying customer which wants it delivered tomorrow and you end up with a
growing legacy of crap that was never intended to live.

I'm afraid what the world does to create software now is a form of
insane heterogeneous mashup and everything, in order to survive, needs
to be able to be contained in and controlled by something else as we
seek elegance :)

PK

On 7/22/2014 8:30 AM, gouessej [via jogamp] wrote:
> Ok. Free software is about freedom after all, feel free to use MS VS
> if you want, I won't spend any time in supporting it as this is what I
> want.
>
> Personally I don't find writing documentation annoying, it's a matter
> of taste. At first, it's useful for me, it allows me to resume a
> project even after a very long pause, I don't waste a lot of time in
> understanding what I did, I know what has been done and what I have to
> do. When I write some documentation, it forces me to think about how
> to explain what I do, it forces me to clarify some aspects so that I
> have a chance in succeeding in explaining my stuff. Secondly, it's
> useful for others even though I don't use silly names for my
> variables. Anyway I understand that some developers find this kind of
> task boring, especially when documenting the work of someone else.
>
> Oh my ... I have just read your bug report and I admit that there were
> some really wrong things :s
> I never use GlueGen under Windows. I run it under Linux a few days ago
> and it worked without any trouble, I used the Ant script within
> Eclipse Kepler. I stopped using the other scripts not based on Ant
> since we switched to JOGL 2 and it seems that I'm not alone in this case.
> Julien Gouesse | Personal blog <http://gouessej.wordpress.com> |
> Website <http://tuer.sourceforge.net> | Follow me on Identi.ca
> <http://identi.ca/gouessej>
>
>
> ------------------------------------------------------------------------
> If you reply to this email, your message will be added to the
> discussion below:
> http://forum.jogamp.org/gluegen-examples-needed-tp4031123p4032623.html
> To unsubscribe from gluegen - examples needed, click here
> <http://forum.jogamp.org/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4031123&code=cGV0ZXJrQGxpdmluZ3dvcmsuY29tfDQwMzExMjN8ODQyNjUwMDMw>.
> NAML
> <http://forum.jogamp.org/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> 
>

By the way - I greatly respect that I was able to install mingw, git clone your source tree, and type "ant" and the build for gluegen, jogl, and jogle-demos just worked. 

It is how I always try to make my stuff work.
PK


On 7/22/2014 8:30 AM, gouessej [via jogamp] wrote:

Ok. Free software is about freedom after all, feel free to use MS VS if you want, I won't spend any time in supporting it as this is what I want.

Personally I don't find writing documentation annoying, it's a matter of taste. At first, it's useful for me, it allows me to resume a project even after a very long pause, I don't waste a lot of time in understanding what I did, I know what has been done and what I have to do. When I write some documentation, it forces me to think about how to explain what I do, it forces me to clarify some aspects so that I have a chance in succeeding in explaining my stuff. Secondly, it's useful for others even though I don't use silly names for my variables. Anyway I understand that some developers find this kind of task boring, especially when documenting the work of someone else.

Oh my ... I have just read your bug report and I admit that there were some really wrong things :s
I never use GlueGen under Windows. I run it under Linux a few days ago and it worked without any trouble, I used the Ant script within Eclipse Kepler. I stopped using the other scripts not based on Ant since we switched to JOGL 2 and it seems that I'm not alone in this case.

Julien Gouesse | Personal blog | Website | Follow me on Identi.ca

---

If you reply to this email, your message will be added to the discussion below:

http://forum.jogamp.org/gluegen-examples-needed-tp4031123p4032623.html

To unsubscribe from gluegen - examples needed, click here.
NAML

Maybe for another thread - let me know.

So I have gluegen working and am putting invocation of it into a build with dependencies.

The source folder will have gluegen config files and the associated code sources.

In our build the desire is to have the source tree be read-only for the build, and have all output go to a temp directory.
So, I want to specify where to place the generated gluegen output from the build script as this could vary depending on the invocation.

How might you suggest accomplishing this?

My thoughts:

If the directives in the config files are overridable with gluegen command line arguments,
ie: the JavaOutputDir,and NativeOutputDir I'll do that.

If not if I include a build generated config file on the command line will it specify those values for all config files following it on the command line if they do not set these values themselves?

If so will the path specified for the output directory be interpreted relative to the config file containing the directive, or to the config file specifying the output to be generated?

Thanks :)

I understand that a developer might need MS VS. I just claim that I won't maintain a second code path in the build system, it's already difficult for me to understand how GlueGen works, there are tons of Ant build scripts and relying on MS VS is quite dangerous but it's possible to build your project with MS VS without requiring the presence of msvcrt on the client machines in order to reduce the risks (I don't remember exactly how except that you can compile statically). A Maven project respecting the default Maven directory layout would be easier to understand.

Maybe Sven knows how to change the output folder... You have to modify src.generated.* for the generated source files too. Look at output.dir too.

You should look at PureSwing, it could be ported to JOGL even though the code hasn't been modified for a while. It uses shaders. As far as I know, it doesn't support JDesktopPane and accessibility but it supports the rest of Swing components.

Thanks - we want to get away from AWT Swing JavaFX entirely for a number of reasons :)
anyway we have the compiling under control :) and this demo is only built for and going to run on a windows8 box.

Thanks on the output folder question.

On 7/22/2014 11:16 AM, gouessej [via jogamp] wrote:

I understand that a developer might need MS VS. I just claim that I won't maintain a second code path in the build system, it's already difficult for me to understand how GlueGen works, there are tons of Ant build scripts and relying on MS VS is quite dangerous but it's possible to build your project with MS VS without requiring the presence of msvcrt on the client machines in order to reduce the risks (I don't remember exactly how except that you can compile statically). A Maven project respecting the default Maven directory layout would be easier to understand.

Mayve Sven knows how to change the output folder...

You should look at PureSwing, it could be ported to JOGL even though the code hasn't been modified for a while. It uses shaders. As far as I know, it doesn't support JDesktopPane and accessibility but it supports the rest of Swing components.

Julien Gouesse | Personal blog | Website | Follow me on Identi.ca

---

If you reply to this email, your message will be added to the discussion below:

http://forum.jogamp.org/gluegen-examples-needed-tp4031123p4032628.html

To unsubscribe from gluegen - examples needed, click here.
NAML