unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Xpdf with or without Qt
@ 2021-02-26 15:43 Andreas Enge
  2021-02-26 16:27 ` Vincent Legoll
  0 siblings, 1 reply; 7+ messages in thread
From: Andreas Enge @ 2021-02-26 15:43 UTC (permalink / raw)
  To: guix-devel

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



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Xpdf with or without Qt
  2021-02-26 15:43 Andreas Enge
@ 2021-02-26 16:27 ` Vincent Legoll
  2021-02-26 17:02   ` Andreas Enge
  0 siblings, 1 reply; 7+ messages in thread
From: Vincent Legoll @ 2021-02-26 16:27 UTC (permalink / raw)
  To: Andreas Enge; +Cc: guix-devel

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


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Xpdf with or without Qt
  2021-02-26 16:27 ` Vincent Legoll
@ 2021-02-26 17:02   ` Andreas Enge
  2021-02-26 17:18     ` Vincent Legoll
  2021-02-26 18:06     ` zimoun
  0 siblings, 2 replies; 7+ messages in thread
From: Andreas Enge @ 2021-02-26 17:02 UTC (permalink / raw)
  To: Vincent Legoll; +Cc: guix-devel

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



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Xpdf with or without Qt
  2021-02-26 17:02   ` Andreas Enge
@ 2021-02-26 17:18     ` Vincent Legoll
  2021-02-26 18:06     ` zimoun
  1 sibling, 0 replies; 7+ messages in thread
From: Vincent Legoll @ 2021-02-26 17:18 UTC (permalink / raw)
  To: Andreas Enge; +Cc: guix-devel

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


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Xpdf with or without Qt
@ 2021-02-26 17:31 Leo Prikler
  0 siblings, 0 replies; 7+ messages in thread
From: Leo Prikler @ 2021-02-26 17:31 UTC (permalink / raw)
  To: andreas; +Cc: guix-devel

> 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



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Xpdf with or without Qt
  2021-02-26 17:02   ` Andreas Enge
  2021-02-26 17:18     ` Vincent Legoll
@ 2021-02-26 18:06     ` zimoun
  2021-02-27 11:23       ` Andreas Enge
  1 sibling, 1 reply; 7+ messages in thread
From: zimoun @ 2021-02-26 18:06 UTC (permalink / raw)
  To: Andreas Enge, Vincent Legoll; +Cc: guix-devel

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


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Xpdf with or without Qt
  2021-02-26 18:06     ` zimoun
@ 2021-02-27 11:23       ` Andreas Enge
  0 siblings, 0 replies; 7+ messages in thread
From: Andreas Enge @ 2021-02-27 11:23 UTC (permalink / raw)
  To: zimoun; +Cc: guix-devel

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



^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2021-02-27 11:23 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-02-26 17:31 Xpdf with or without Qt Leo Prikler
  -- strict thread matches above, loose matches on Subject: below --
2021-02-26 15:43 Andreas Enge
2021-02-26 16:27 ` Vincent Legoll
2021-02-26 17:02   ` Andreas Enge
2021-02-26 17:18     ` Vincent Legoll
2021-02-26 18:06     ` zimoun
2021-02-27 11:23       ` Andreas Enge

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).