Java-Gaming.org Java4K winners: [ by our judges | by the community ]         
Featured games (67)
games approved by the League of Dukes
Games in Showcase (∞)
games submitted by our members



News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  Print  
  jogl 1 vs 2 semi-bug  (Read 702 times)
0 Members and 2 Guests are viewing this topic.
Offline mahogny

JGO n00b
*

Posts: 12



« on: 2010-03-26 08:41:08 »

it must be possible to have jogl1 & jogl2 installed at the same time.

e.g debian places all .so-files in the same directory. different programs will need different versions. you would simplify it greatly for us if everything was named libjogl2_*. likewise there would be no complaints if you did the same for the jar-files.

just ran into a hard to track down bug related to this, it found the jogl1-so's instead of jogl2 :/

thanks
Offline bienator

JGO Ninja
***

Posts: 632
Medals: 1


OutOfCoffeeException


« Reply #1 on: 2010-03-26 13:06:28 »

hmm.. we probably won't change that.

IMO it is responsibility of the module system to manage such conflicts.
If you take a look at /usr/lib/ you should find several *.so.VERSION files like:
libopenal.so.1
the .1 was added by the module system(->package manager), not by the module provider.

(if you are moving jogl manually around... don't forget gluegen-rt etc)

Offline mahogny

JGO n00b
*

Posts: 12



« Reply #2 on: 2010-03-29 11:00:34 »

Well, the .1 wasn't added automatically in that case. Rather the one who packaged OpenAL downstream modified the code. Since this would have to be done for each package system (redhat, ubuntu, gentoo, you name it) and each program using jogl, it would save a lot of collective effort if it was done once and for all, and no patches would have to be maintained (or fewer). As a bonus side-effect, people wouldn't come up with multiple solutions; this helps those who take one package and tries to hack it to work on another distribution.

Some packager tools would also benefit e.g. those that try to detect libraries; they can't easily detect major versions at the moment.
Games published by our own members! Go get 'em!
Offline bienator

JGO Ninja
***

Posts: 632
Medals: 1


OutOfCoffeeException


« Reply #3 on: 2010-03-29 12:17:22 »

but this is really the responsibility of the linux distribution. We have module systems to solve that. We would have to increment the version in the name of every artifact every time we make a change... thats what i try to prevent. Filenames are no module versions.

anyway, the single conflict we currently have is gluegen-rt.jar... maybe we can do something about that.

Pages: [1]
  Print  
 
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.16 | SMF © 2011, Simple Machines Valid XHTML 1.0! Valid CSS!
Page created in 0.097 seconds with 20 queries.