Is there any changes this patch could be applied ? It would avoid future conflicts.

I currently added armv7l eabi (linux/ubuntu(debian)) and android for gluegen, jogl is in progress,
see branch wip_mobile.

I will also finish crosscompilation and testing, soon.

Would be interesting how to add 'default' builds, 
i.e. w/o specific setting eg. compiler.cfg.linux instead of compiler.cfg.linux.x86, ..

Also, we should be able to confirm / test the builds somehow, shouldn't we ?
I assume you have tested your setup, ofc. 
Soon I will add the above mentioned armv7l eabi machines to our jenkins system.

ARMEL / Linux works, as well as ARMEL / Android (w/ a custom config).

I don't know if you like to add the other platforms as well
and whats the status of build machines for such.

Shall we keep this bug open ?

Yes please. 
I updated part of my patches against the rc3. It is a long and boring work, it would be nice if you could consider the inclusion of the patch (I will send the new one in the new few days).

Yes, I will merge - THANK YOU.
(Just send me a note here - hope it's not a too much intrusive change.)

Again: Whats the status of those platform's build / test machines ?
Shall we silently assume they just work ? Can you provide a URL 
where we can see (I assume) debian build / test logs ?
Or is anything like this planned ?

Shall we add the creation of debian packages to our Linux build ?

Created attachment 308 [details]
Fix bug 488

I lagged a bit but yeh, we are still in 2011!
  
> Again: Whats the status of those platform's build / test machines ?
> Shall we silently assume they just work ? Can you provide a URL 
> where we can see (I assume) debian build / test logs ?
https://buildd.debian.org/status/package.php?p=gluegen2&suite=experimental
there is a s390x build issue but it should be fixed when you read this comment.

Note that hurd & kfreebsd are failing because the port of the openjdk is not over yet.


For gluegen2, you can consider that it is working since it builds jogl2
https://buildd.debian.org/status/package.php?p=libjogl2-java
(the armel build issue will be fixed soon)

> Shall we add the creation of debian packages to our Linux build ?
No, it is not necessary, I am happy with a separate repository.

Awesome !

I guess we need to patch Platform.java as well, since it reassembles the os-and-arch.
We also need to determine on these new values other information, 
ie 32/64 bit and validate the MachineDescription (alignment, ptr-size, ..).

commited under your name: 196c325aa3dddb0d775e8fb80e26333208fe6c7e

Until issues in comment 8 are resolved we need to keep this bug 
and it's dependent 547 open ..

You are right. I will fix that!

Any chance we can complete this (MachineDescriptions) ?

Sylvestre, I can also do the fix - if you would dump the *runtime* MachineDescription (MD)
here (attachment) for all the new platforms.

You can simply do that while running 'com.jogamp.common.GlueGenVersion'.
In case the compile time version doesn't match the runtime, an exception is thrown,
still showing the desired data.

Then I could extend the compile-time static build in MD table
if required, ie. the current one doesn't cover the new platforms.

By the way, the reason I am choosing the static MD to enhance runtime performance.
It is important to understand that the alignment data not only depends on the CPU 
itself, but on the compiler and compile-time flags (-pthreads, ..).

The more things develop currently (ABI change, C++11, multiple platforms),
we may consider to throw out the static MD and favor the runtime MD,
even though this may impact performance a little bit.

What do you think ?

+++

I also would like to align the ARM ARMv7 etc .. specs to remove duplication.

+++

Sorry about the lag. I tried but I was stuck on that stuff:

    public enum CPUFamily {
        /** AMD/Intel */
        X86(    0x00000000), 
        /** ARM */
        ARM(    0x00010000),



    public enum CPUType {
        /** X86 32bit */       
        X86_32(    CPUFamily.X86,     0x0001),
        /** X86 64bit */
        X86_64(    CPUFamily.X86,     0x0002),

I don't know how to get this information ?!
Could you detailed me how you get them initially ?

thanks

ping ?

Hi Sylvestre, sorry, I don't regular react in real time on email notification re bugzilla,
pls send me a private email as well in case you like a more instant response.

Reading your question in comment 13, I don't know what information you like to have.

The 'table' of os.and.arch information is arbitrary, i.e. made up by us
following our runtime/build constraints of having the same os.and.arch setup.

The runtime values are determined within Platform's static initializer
and shall match gluegen's cpptask determinations (java CPU/ARCH identifiers).

Maybe we can chat in our chatroom conference.jabber.org ?