what problem is this trying to address? AFAIK there is no need to bootstrap the ijs directory unless one is building the ijs library and the examples. gs just compiles one or two of the files and include them, and does not need the library being built.

I probably don't understand the dependency to is right. As a packager I build IJS
as it now comes with Ghostscript:
  http://www.openprinting.org/download/ijs/
When I compile Ghostscript with a bootstrapped ijs library this results in a dependency
from ghostscript to the ijs library:
  https://buildfarm.opencsw.org/source/xref/opencsw/csw/mgar/pkg/ghostscript/trunk/Makefile

Would you recommend not building the ijs library at all and just let ghostscript
use the headers and not link against libijs?


Best regards

  -- Dago

(In reply to Dagobert Michelsen from comment #2)
...
> Would you recommend not building the ijs library at all and just let
> ghostscript
> use the headers and not link against libijs?
...

(My opinion is in no way official - I am just a seasoned user/contributor) 

Many believe in shipping a shared library for reasons of single maintainence and ease of upgrade. In this case, the reason is not particularly strong - 
The page http://www.openprinting.org/download/ijs/ is somewhat outdated - ghostscript development moved to git about 6(?) years ago? The ijs code has not changed for years, and very few pieces of software use it besides ghostscript.

The ijs code has not changed for about 14 years, I think; Both hplip/hpijs and Epson EPL driver are shipped with its own copy of the ijs code. (this part is an "authoritative" answer as I am one of the main authors of the EPL driver), and AFAIK, gutenprint seems to be moving away from ijs and using cups API instead, and so is is hplip.

So your decision depends on whether you ships any of those three, and whether you actually override their default (in the case of hplip and epson epl at least) to *not* use their bundled ijs code?

If you don't ship any of the 3, there is no need to build ijs as a library.

Hi,

does that mean that not bootstrapping ijs and not shipping it separately has no negative effect on Ghostscript as the relevant files and headers will be included anyway?

Best regards

  -- Dago

(In reply to Dagobert Michelsen from comment #4)
> does that mean that not bootstrapping ijs and not shipping it separately has
> no negative effect on Ghostscript as the relevant files and headers will be
> included anyway?

That's correct AFAIK. Unless you go through some effort (I am not aware any party say, linux distro does, though I seem to think that Debian may, at some point in the past), half of ijs is built into ghostscript, and the opposite half is bundled and built into hplip/epson epl; if you care about status of gutenprint's ijs functionality, you should check. There is no strong need to ship the library or header files separately.

For example, on the fedora linux box I am typing this right now,
"ldd /usr/bin/gs | grep ijs" and "ldd /usr/bin/hpijs | grep ijs" are both empty,
and there is no libijs* on the system, while "gs -h | grep ijs" shows ijs is built in. These are as Redhat ships them.

Can we clarify: is this in relation to building Ghostscript, or to building the ijs server?

I'm not aware of the status of the ijs server code in our distribution - I'd always assumed it was there purely for convenience of testing the ijs device in Ghostscript, and that it was not an "upstream" source for the server code....

(In reply to Chris Liddell from comment #6)
> Can we clarify: is this in relation to building Ghostscript, or to building
> the ijs server?
> 

Not about building ghostscript, just libijs and the example ijs server (and the example client), I think.

> I'm not aware of the status of the ijs server code in our distribution - I'd
> always assumed it was there purely for convenience of testing the ijs device
> in Ghostscript, and that it was not an "upstream" source for the server
> code....

That's not true, I believe. There is "no" upstream. The ijs code was developed between Raph Levien when he was with ghostscript, and the HP people working on HPIJS. As you know, Raph has moved on, and most of the original people working on that code in HP have been re-assigned too. AFAIK the full set exists in the ghostscript repository, and ghostscript only uses the client side code (and compiling it in), and the server-side code is shipped with HPIJS/HPLIP and possibly also the other ijs servers.

(In reply to Hin-Tak Leung from comment #7)
> (In reply to Chris Liddell from comment #6)
> > Can we clarify: is this in relation to building Ghostscript, or to building
> > the ijs server?
> > 
> 
> Not about building ghostscript, just libijs and the example ijs server (and
> the example client), I think.

Are you sure? Because the OP says: "When building Ghostscript 9.15....."

Well, if you bootstrap ijs and build it you get a ghostscript which links against
libijs-0.35.so. This led me to the assumption that ghostscript somehow benefits
from having it built.

(In reply to Dagobert Michelsen from comment #9)
> Well, if you bootstrap ijs and build it you get a ghostscript which links
> against
> libijs-0.35.so. This led me to the assumption that ghostscript somehow
> benefits
> from having it built.

Hmm.... Ghostscript will only (try to) link against libijs-0.35.so if the GS configure script doesn't find the 'ijs' directory in the source distribution. If the 'ijs' directory is found, it will build the ijs client code in statically (and ignore the server code).

Given the size of the ijs client code, I feel it's preferable to have it built in statically - it'll use far more resources loading the shared library than the code actually occupies.


Anyway, my inclination is to just commit the results of running autogen.sh to our git repo - it hasn't changed in a long, long time, and is unlikely to change in the future. Even if it does, it's unlikely to change often enough for it to be a problem.

You are right, our package contents verification showed a dependency from ghostscript
to libijs and I got the impression that it was needed. After going into detail now
I saw that only the examples
  ijs_client_example
  ijs_server_example
are linked against libijs. For me it is ok to skip ijs building now.

Thanks! -- Dago

As mentioned above, I've committed the "bootstrapped" files to git, so it will be so in the next and subsequent releases.