Bugzilla Bug 184844

DjView4 is a new portable DjVu viewer and browser plugin using Qt4. It has more
functionality than djview3 included in app-text/djvu.

Ebuild attached. Should probably go in app-text.

Created an attachment (id=124427) [details]
first ebuild

Please read the project page. The viewer is now separated from djvu. There is
no djvu-4.1, but a new package djview-4.1 that depends on app-text/djvu.

I do not have qt-4 installed and I doubt I'll install it before kde-4, so if
anybody have interest, take it, please.

Thanks. Now if somebody could fix the typo so that it reads "app-text/djview4"
it would be great.

added as app-text/djview4: upstream 4.1-2 is 4.1.2 for us.

Thanks Stefan ! 


I made small changes, esp. : removing the nsplugin useflag, as your approach of
built_with_use won't work : imagine I  build djvu without nsplugin, then
djview4 with nsplugin then djvu with nsplugin, that will collide.
as djvu is the main package, I suppose it's better that it remains the one that
provides the plugin browser. Perphaps we could do something about that to have
the choice, but the only thing I can think of is to talk with upstream and ask
them to give djview4 nsplugin a different name.

I think the browser plugin is basically the same as in the 3.x version. At some
point djview will be separated from the djvu package and we won't have this
problem. Until then, we should compile djvu with the qt3 flag to get the
plugin, even if we don't use djview3...

If you have the time, could you please explain me why the  use of:
"emake CC=$(tc-getCC) CXX=$(tc-getCXX)"
Is there a toolchain w/o CC and CXX set? Thanks.

> If you have the time, could you please explain me why the  use of:
> "emake CC=$(tc-getCC) CXX=$(tc-getCXX)"
> Is there a toolchain w/o CC and CXX set? Thanks.

that's just to call gcc/g++ with their full names. gcc/g++ are usually the
native compilers and it defaults to them for CC and CXX. Without that you have
pain cross compiling the package or have to do some hacks while using distcc
over different arches

Then why not putting it in emake?

(In reply to comment #8)
> Then why not putting it in emake?


Usually there is no need for this, but I suppose the way they use autotools +
qmake does not handle it. But you're right, if that annoys someone he can just
add the correct options to MAKEOPTS in make.conf.