Bugzilla Bug 22217

What is OpenDX?

Open Visualization Data Explorer is a visualization framework that gives users
the ability to apply advanced visualization and analysis techniques to their
data. These techniques can be applied to help users gain new insights into data
from applications in a wide variety of fields including science, engineering,
medicine and business. Data Explorer provides a full set of tools for
manipulating, transforming, processing, realizing, rendering and animating data
and allow for visualization and analysis methods based on points, lines, areas,
volumes, images or geometric primitives in any combination. Data Explorer is
discipline-independent and easily adapts to new applications and data. The
integrated object-oriented graphical user interface is intuitive to learn and
easy to use. For more information, select the What is IBM Open Visualization
Data Explorer? link listed below. 

See sample images:

http://www.research.ibm.com/dx/imageGallery/index.html

Reproducible: Always
Steps to Reproduce:
1.
2.
3.

I think this is the latest official website:

http://www.opendx.org/

This looks really interesting but it's going to take a fair bit of work to
get ebuilds together for it. I'm taking a little time to try it out and see
what happens.

Status update: I've got an opendx ebuild I think will work fairly well, and
I'm working on ebuilds for some dependencies: HDF4, CDF, and jasper. I'm
still on the first of those three due to some time constraints.

Created an attachment (id=20505) [details]
opendx-4.3.0.ebuild

Created an attachment (id=20506) [details]
license

Reassigning to sci so the rest can see what's going on and help with dependency
ebuilds if they want. =)

Ebuilds still need to be made for HDF4 (HDF5 is in portage already, but this
doesn't work with it), CDF (http://nssdc.gsfc.nasa.gov/cdf/cdf_home.html),
and Jasper (http://www.ece.uvic.ca/~mdadams/jasper/). I tried to start on
HDF4 but haven't gotten anywhere.

an experimental hdf4 version is in portage now. About CDF - doesn't netcdf
work? I 'll give it a try.

I believe cdf and netcdf are distinct entities, but not 100% sure.

please note that 4.3.2 is out

I noticed a little late that there already was a "jasper" ebuild around - see
bug 35358

Created an attachment (id=22338) [details]
patch for the ebuild

Patch for the old ebuild. This compiles fine on my system, even seems to run,
but it has several problems to be addressed:

- the USE orgy of the old ebuild seemed a bit much for me - do you really think
we should introduce so many local USE flags for this?
- I disabled CDF support, it currently only uses netCDF.
- it installs stuff to /usr/dx which is not very nice, FHS-wise. We should make
it go into FHS-compliant locations before releasing an ebuild.
- I am sure I have forgotten something :-)

In my opinion, everything that has a possibility of being a USE flag should be.
Thus the "orgy." If they can't be global, they'll have to be local. Would you
rather force-disable things people may want, or force-enable unnecessary
dependencies? I see the current solution as better than those options.

Why disable CDF? Just because of no ebuild, or is there more?

Is /usr/share/dx FHS-compliant?

Ok, having all those USE flags probably makes sense - just please announce them
on -core before silently using them and add them to use.local.desc if they
can't be made global. And we will have to test a few more compile time option
combinations for this monster...

I currently disabled CDF just because it's not yet there. No other idea behind
that. But I think before adding CDF we should check if it offers anything
better than netCDF.

About the jasper dependency - we have it in now, but grepping through the
opendx sources I get the impression that this is no direct dependency. Perhaps
it is used by ImageMagick if available? We should check this.

/usr/share/dx wouldn't be any better since only platform-independent files
belong into share. If we can't force it to split up properly without producing
a total mess, maybe /usr/dx is ok for a start. Not FHS, but /usr/kde and
/usr/qt aren't FHS-compliant either...

Agree on the USE flags and compile-time options. IRT the USE orgy, I seem to
remember even more configure options with image types but I'll be on a dialup
connection for the next three weeks so not much downloading will be happening.

http://www.opendx.org/compiling-dx.html :
"CDF, netCDF and HDF are data file format libraries. CDF and netCDF are
required to run the samples and tutorial."

More tips and functions for each library here:
http://www.opendx.org/compiling-libs.html

I don't see anything clear for jasper either. Perhaps we should fix our
imagemagick build to use it, since it doesn't now.

I wasn't thinking clearly when I asked about the FHS thing, forgive me. =) It's
been a long few days.

Created an attachment (id=22540) [details]
patch for old ebuild

Ok, brought back the USE flags and added CDF to portage. This works quite
nicely for me (still installs into /usr/dx) - please test and report if you
find problems or if this can go into portage.

I disabled java support since I was not able to make it compile properly with
java enabled.

Patrick,
You've really done some fantastic work here, with all the libs and the work on this. Nice job!

I'll download and take a look at this over the next couple of days.

The only problem I have with it is that the image format USE flags (at least tiff, I don't remember what else) require the imagemagick flag AFAIK. Do you know if nested USE works yet?

For example:
    imagemagick? (
        >=media-gfx/imagemagick-5.3.3
        media-gfx/jasper
        tiff? ( media-libs/tiff )
        mpeg? ( media-libs/mpeg )
    )

And so forth... again I know I don't have all the options quite right.

Nested USE works. At least I used it in the last ethereal ebuild :-)

About tiff support, different from the documentation I think that imagemagick is not required. From the ./configure run:

configure: checking for TIFF support ......
checking tiff.h usability... yes
checking tiff.h presence... yes
checking for tiff.h... yes
checking tiffio.h usability... yes
checking tiffio.h presence... yes
checking for tiffio.h... yes
checking for TIFFOpen in -ltiff... yes
checking if TIFF package is complete... yes

That doesn't look like an indirect dependency. Looks like the documentation is not up-to-date regarding this aspect - perhaps we should report this when we have a final tested version of the ebuild.

Jasper is different, I think it's something that should better be handled by the imagemagick ebuild.

Hey guys, so what's the status on this?

I am asking because I see hdf flag listed in use.local.desc and referencing this package, but apparently the opendx itself is not in the tree.

Actually my interest was in hdf use flag. The thing is app-sci/octave has optional support for hdf5 and, potentially, it might be worth using one common flag (and thus making it global). However I see that opendx uses plain hdf[4], so technically this is different. Although it still should work with plain hdf use flag, - every app will use the corresponding version of hdf (they come as different packages because of format incompatibilities). So it might be worth sticking with just one flag..

What do you think?

For now I added hdf5 to use.local.desc, but this will need to be revisited, when this bug gets resolved.

George

Patrick's modified the ebuild some, but he's away for the month of January. I'm
not sure whether he has further local modifications that aren't up here so I'm
hesitant to commit this.

IRT the hdf USE, I think this might be a good hdf4 flag and you could use
either hdf or hdf5 for the "new hdf." It might be a good idea to have separate
flags in case a package supports both hdf4 and and hdf5, although I'm not aware
of any.

I didn't change anything since the last patch you find here - indeed I was
hoping to find a working OpenDX in portage when I am back :-)

The ebuild will still need a bit work, for example the jasper stuff seems to
belong into imagemagick. No reaction from the graphics guys so far, see bug
#36349 for that problem.

Created an attachment (id=25551) [details]
opendx 4.3.2 ebuild

Created an attachment (id=25552) [details]
opendx-samples 4.3.2 ebuild

Hi folks,

I made these ebuilds for opendx and opendx-samples.
They are very simple, and do not have USE flags for installation customizing,
but worked very well for me, including with javadx.
Maybe it helps.

-- Nilton

Created an attachment (id=26546) [details]
opendx-4.3.2.ebuild

Here's my latest ebuild. A full build of 4.3.2 (all USE enabled) dies, however.
Haven't tracked it down yet.

Created an attachment (id=26547) [details]
failed compilation log of 4.3.2

If anyone cares to contribute ideas, take a look.

Hm, a different error this time. Made it through compilation, got this on
install.

sh ../mkinstalldirs /usr/local/build/portage/opendx-4.3.2/image//usr/dx/html
make  install-data-hook
make[4]: Entering directory
`/usr/local/build/portage/opendx-4.3.2/work/dx-4.3.2/html'
make[4]: *** No rule to make target `install-data-hook'.  Stop.

Donnie, perhaps it's a parallel build problem?

Heh, I actually had that idea earlier today but I forgot it. Thanks for
reminding me.

Managed to reproduce the problem in comment #25 with a non-parallel build.

OK, this is a little odd. It was the doc flag I added (`use_with doc
installhtml`). Whether it's on or off, it seems broken, but if it's not there
at all it works.

use_enable, rather

Created an attachment (id=26672) [details]
opendx-4.3.2.ebuild

So, here's my final version. Patrick, wanna look over this and try it out?

Donnie, I'd say let's bring this into portage as soon as possible and attract
testers. I just removed the dependency on bug 36349 because jasper support is
nice, but we can survive without it. Agree?

Sounds good.

Donnie, just for the case you're waiting for me to commit this - I am waiting
for you do commit it :-)

Heh, OK. I was. I'll commit soon.

Donnie, could you please make a last minute change before committing? We are
allowed to mirror the sources.

Committed. Thanks for playing.