CImg & clapack inclusion

[GoogleCodeExporter]

It seems that photivo includes greyc and Lapack in its source tree.

In order to package it properly, we need to remove them from here, and have 
them as external dependencies.
Most distribs have a lapack and GREYCstoration -devel package.

Also, as mentioned in #9, will you provide regular source snapshots? This would 
help to determine the version numbering scheme.

Thanks,
Thibault

Original issue reported on code.google.com by thibault...@gmail.com on 27 Apr 2011 at 8:36

[GoogleCodeExporter]

Since it is in the source it does not conflict with any installed versions, so 
why do you see the need to change this? Which distribution has problems with it?

Source snapshots are done by Brother John everytime he releases a new Windows 
binary.

greets mike

Original comment by m...@mm-log.com on 27 Apr 2011 at 9:29

[GoogleCodeExporter]

True, it doesn't create any conflict. But the dependency ensures that an 
updated version of these libs is used, and limits security issues.

If you are using unpatched versions of these libs, if would be better to do so.

I would like to prepare a Fedora package. It is strongly discouraged to compile 
as static with libs that could be shared with the system.
http://fedoraproject.org/wiki/PackagingGuidelines#Shared_Libraries

cheers,
Thibault

Original comment by thibault...@gmail.com on 27 Apr 2011 at 9:44

[GoogleCodeExporter]

BTW, lensfun database is also duplicated. 
If lensfun is updated system-wide, photivo won't be able to use the new db 
without being updated, and assuming you have also imported its last version.

Original comment by thibault...@gmail.com on 27 Apr 2011 at 9:46

[GoogleCodeExporter]

Well, I would need to test against the delivered packages and we would have to 
see if there are problems on Windows building it. I'm still busy, so please 
don't expect these changes soon.

greets mike

Original comment by m...@mm-log.com on 27 Apr 2011 at 9:47

[GoogleCodeExporter]

Yes, don't worry. I attempted to package photivo a few month ago, but we had no 
16bits GraphicsMagick in Fedora. This will change, so I'll attempt to package 
it again and will report here the small issues I see here.

Thanks,
Thibault

Original comment by thibault...@gmail.com on 27 Apr 2011 at 9:53

[GoogleCodeExporter]

It seems to me that openSUSE repositories don't include clapack and 
GREYCstoration. So I need them is the Photivo sources to build RPMs.

Original comment by salser...@gmail.com on 28 Apr 2011 at 4:55

[GoogleCodeExporter]

Re source snapshots: I stopped providing them because they don’t serve a real 
purpose. It’s almost just as easy to get the code from the repo. And Photivo 
doesn’t have any version numbers, so just because I used revision X to build 
a Windows installer doesn’t mean revision X is special in any way. Bascially 
we try to keep the default branch in the repo clean and bug free enough that it 
is fit for packaging at any time.

Original comment by brother.john.gm@googlemail.com on 28 Apr 2011 at 8:07

[GoogleCodeExporter]

Any update on that issue ?

Original comment by thibault...@gmail.com on 26 Nov 2011 at 4:04

[GoogleCodeExporter]

Following up on your reminder: kind of. :)

I removed the clapack dependency from the project, it was only used by the 
unfinished (and unavailable in the GUI) Refocus sharpen anyway. If/when someone 
finishes Refocus I don’t see too much of a problem with switching to lapack 
as a shared lib. Distris’ repos usually seem to have it.

Also updated cimg to the current version 1.4.9. But cimg doesn’t seem to be a 
natural part of distri’s repos; at least I couldn’t find it in the Fedora 
repos. cimg development isn’t exactly lightning fast anyway, so I think we 
can live with having it in the source tree. Also currently it works out of the 
box on Windows, which is always a plus.

Regarding distri repos: I’m mainly a Windows guy, so feel free to correct me 
on the repo stuff. I’m not too familiar with that.

Original comment by brother.john.gm@googlemail.com on 28 Nov 2011 at 10:16

[GoogleCodeExporter]

Thanks :)

(Did you actually remove clapack in that commit: 
http://code.google.com/p/photivo/source/detail?r=1e2d9c5e33db5826bcebadcd9e4e6b7
7ab221cc4 ) ?
You are right, CImg is not in Fedora (yet).
Regarding Fedora packaging guidelines, the proper way to do it is to compile 
and link against CImg. Perhaps we could have an option to either build it with 
CImg as an external library or use the version included in the source files.

Thank you very much,

Original comment by thibault...@gmail.com on 28 Nov 2011 at 1:29

[GoogleCodeExporter]

Right, that’s the commit.

No need for an option, the update was a quick and dirty improvement that 
required no effort. Eventually we’ll have a shared cimg, it’s just not at 
the top of mike’s or my todo list.

We’d have to put together build instructions for Windows/MinGW/Msys and for 
the distris that don’t have it in their repo; and tell Photivo to use the 
shared lib instead of the in-source one. All in all, doesn’t sound overly 
complicated. If you like to help out, that’d be great. :)

Original comment by brother.john.gm@googlemail.com on 28 Nov 2011 at 7:46

• Changed state: Postponed

[GoogleCodeExporter]

Hi,

CImg will (hopefully) be in Fedora soon, this is the review request:
https://bugzilla.redhat.com/show_bug.cgi?id=852898

I have also done a patch for photivo to use a system-supplied CImg instead of 
the internal one. The goal was to do a minimal-invasive approach and allow to 
select between system CImg and internal copy with a configure switch at qmake 
time.

You can find the patch here:
https://raw.github.com/gvegidy/photivo-rpm/master/photivo/photivo-system-cimg.pa
tch

To activate the system CImg you just call
qmake-qt4 "CONFIG+=WithSystemCImg"

On a side-note: when you upgrade the internal CImg to 1.5.0 or beyond, you also 
need this patch:
https://raw.github.com/gvegidy/photivo-rpm/master/photivo/photivo-cimg-150.patch

Please consider applying these patches. That would ease creating a proper 
Fedora package.

Original comment by gerdveg...@googlemail.com on 1 Sep 2012 at 3:32

[GoogleCodeExporter]

Thank you. A qmake switch is indeed a nice and easy way to make everyone happy. 
We’ll be happy to include your changes. I’ll push them in a few minutes.

Original comment by brother.john.gm@googlemail.com on 1 Sep 2012 at 6:22

[GoogleCodeExporter]

This issue was closed by revision 926799865de3.

Original comment by brother.john.gm@googlemail.com on 1 Sep 2012 at 6:28

• Changed state: Fixed