Xpdf with or without Qt

Xpdf with or without Qt

[Andreas Enge]

Hello,

commit 35089dca4053bf5888441d1648086cdadb6eb1e4 adds Qt to the xpdf package
and removes most X libraries. The result is quite different and does not
correspond to the synopsis "...based on the Motif toolkit" any more, and we
get closer to more modern pdf readers such as evince or okular. On the other
hand, I have been using xpdf as a "no frills" reader with an interface that
had not changed forever, which I am missing now.

Is this a change that became necessary with the update from 4.02 to 4.03
(that looks minor from the numbers!)? If no, I would like to suggest getting
back to the previous inputs. If yes, I do not quite know what to do :)

Andreas

Re: Xpdf with or without Qt

[Vincent Legoll]

Hello Andreas,

On Fri, Feb 26, 2021 at 4:43 PM Andreas Enge <andreas@enge.fr> wrote:
> commit 35089dca4053bf5888441d1648086cdadb6eb1e4 adds Qt to the xpdf package
> and removes most X libraries. The result is quite different and does not
> correspond to the synopsis "...based on the Motif toolkit" any more, and we
> get closer to more modern pdf readers such as evince or okular. On the other
> hand, I have been using xpdf as a "no frills" reader with an interface that
> had not changed forever, which I am missing now.
>
> Is this a change that became necessary with the update from 4.02 to 4.03
> (that looks minor from the numbers!)? If no, I would like to suggest getting
> back to the previous inputs. If yes, I do not quite know what to do :)

Yes, it fails without it:

CMake Warning at CMakeLists.txt:32 (message):
  Couldn't find Qt4 or Qt5 -- will not build xpdf.

From the xpdf INSTALL file:
* Make sure you have the following installed:

    - CMake 2.8.8 or newer
    - FreeType 2.0.5 or newer
    - Qt 4.8.x or 5.x (for xpdf only)
    - libpng (for pdftoppm and pdftohtml)
    - zlib (for pdftoppm and pdftohtml)

  If Qt isn't found, the GUI viewer (xpdf) won't be built, but the
  command line tools will still be built.

This is also documented here:
http://www.xpdfreader.com/download.html

There may exist a cmake param to get the old bare xpdf, but
I've not found it.

-- 
Vincent Legoll

Re: Xpdf with or without Qt

[Andreas Enge]

Hello Vincent,

thanks for your quick reply!

Am Fri, Feb 26, 2021 at 05:27:47PM +0100 schrieb Vincent Legoll:
>   If Qt isn't found, the GUI viewer (xpdf) won't be built, but the
>   command line tools will still be built.

Okay, I see. So they changed the program, and we should follow, although
I am not that happy about it - for a "more standard" pdf reader, I might
as well switch to evince or okular.

So I would like to ask a help-guix type question (but keep it here since
the context is already set up):
How can I personally keep the old variant?
Should I create a custom channel with xpdf@4.02? Or even xpdf@5 to have
a higher version number, but with the old 4.02 package code and source?
Or a manifest including some time-machine thing, or a personal package
transformation that compiles xpdf --with-source=...?

Andreas

Re: Xpdf with or without Qt

[Vincent Legoll]

In retrospect, I should probably have added a note in the commit
message that it would be a somewhat major change. With an
emphasis on the X -> QT migration.

On Fri, Feb 26, 2021 at 6:02 PM Andreas Enge <andreas@enge.fr> wrote:
> How can I personally keep the old variant?
> Should I create a custom channel with xpdf@4.02? Or even xpdf@5 to have
> a higher version number, but with the old 4.02 package code and source?
> Or a manifest including some time-machine thing, or a personal package
> transformation that compiles xpdf --with-source=...?

I don't really know the answer to this, but if you're copying the old code,
just name your "pinned" package "xpdf-4.02" so that it's not recognized
as "xpdf", and that should protect you from xpdf upgrades.

-- 
Vincent Legoll

Re: Xpdf with or without Qt

[zimoun]

Hi Andreas,

On Fri, 26 Feb 2021 at 18:02, Andreas Enge <andreas@enge.fr> wrote:

> How can I personally keep the old variant?

I would go with inferior.

  <https://guix.gnu.org/manual/devel/en/guix.html#Inferiors>

--8<---------------cut here---------------start------------->8---
(use-modules (guix inferior) (guix channels)
             (srfi srfi-1))   ;for 'first'

(define channels
  ;; This is the old revision from which we want to
  ;; extract xpdf
  (list (channel
         (name 'guix)
         (url "https://git.savannah.gnu.org/git/guix.git")
         (commit
          "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"))))

(define inferior
  (inferior-for-channels channels))

(packages->manifest
 (list (first (lookup-inferior-packages inferior "xpdf"))
       (map
         specification->package
         (list
           "foo"
           "bar"
           …))))
--8<---------------cut here---------------end--------------->8---

where xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx is the last commit
containing the version you like.


Hope that helps,
simon

Re: Xpdf with or without Qt

[Andreas Enge]

Thank you, Vincent, Leo and Simon for all your suggestions!

I note that they differ in whether xpdf gets recompiled when dependencies
change (keeping a package around in a scheme file or channel) or not (using
inferiors or a separate, not updated profile); probably both may have their
advantages and disadvantages in practice.

Andreas

Re: Xpdf with or without Qt

[Leo Prikler]

> Should I create a custom channel with xpdf@4.02? Or even xpdf@5 to
> have
> a higher version number, but with the old 4.02 package code and
> source?
> Or a manifest including some time-machine thing, or a personal
> package
> transformation that compiles xpdf --with-source=...?
It's up to you, but some options are worse than others.
The easiest thing would be to inherit xpdf in your manifest and build
it from the old source.  That should work pretty well and also update
xpdf if any of its dependencies change.  You could also copy the entire
4.02 recipe to your history channel.  Either way, make sure to refer to
it as xpdf@4.02 when installing from command-line or directly by
variable xpdf-4.02 when using it in a manifest.  Do not create "higher"
versions for your own needs (unless they actually make sense, e.g.
you're packaging the yet unavailable version 4.04-alpha-we-got-back-
motif), that would conflict with Guix if a version 5 shipped, that had
Qt as an optional input with a Motif fallback.
Another would be to use inferiors from a manifest.  Inferiors basically
work like time-machine, but expressed in terms of Scheme code.
A third option would be to generate an environment, that has xpdf@4.02
through time-machine and add that environment as a gcroot.  Then you can invoke xpdf commands from that path and even source its etc/profile (inside your .bash_profile for instance) at startup.

Which one you grok the most is up to you, but it's definitely fun to
experiment 🙂

Regards,
Leo