Compilation error (gcc 4.1.0, cups.h)

Logged In: YES
user_id=296574

Installing package cups-devel with YaST
did not modify the config.log but make
succeeded.

cups-config did exist earlier too it
is only the headers that are installed
with cups-devel...

Lowering prio... (close as invalid?)

Logged In: YES
user_id=5436

Gutenprint relies on cups-config to tell it how to compile
the CUPS driver, which is the normal protocol for this
purpose. It's behaving as intended, so I am closing this.

Logged In: YES
user_id=296574

Searched SuSE bugzilla...

It was actually moved to cups-lib to fix another bug...

https://bugzilla.novell.com/show_bug.cgi?id=142004

I will reopen that report.

Logged In: YES
user_id=5436

I read the discussion on the SUSE bug. I notice that for
other packages (e. g. gtk) the *-devel script is in the
devel package. As I see it, cups-config is reporting the
wrong thing -- it shouldn't be reporting that it's possible
to compile against CUPS if it isn't.

Maybe SUSE needs to modify its cups-config to not report how
to usefully compile a CUPS application if the devel package
isn't installed.

Logged In: YES
user_id=1542465

Hello,
sorry to say, but relying on cups-config is from our point
of view not enough. :( The reason is that cups-config is
nowadays "misused" to provide many more information than
just compilation options. These information (e.g.
--serverbin) is used by other 3rd party vendors to get the
right location of their driver.

Therefore we detected this as an issue, and need to have
cups-config always avail, for the unexperienced user, in
an CUPS based system.

Now came up =an additional problem: some more experienced
users (those who are able to start a compiler), have the
strange opinion that it is an issue to have cups-config
(without header files) present, but are unwilling to check
error messages, nor want to check if the required *-devel
packages are present in their system.

Can you please add a so called idiot-proofed check in the
configure phase: to check whether cups/cups.h is present
(additional to check whether cups-config is present)?

Thanks in advance.

Regards,
Klaus Singvogel (SUSE/Novell developer)

Logged In: YES
user_id=5436

I'd like Mike Sweet's opinion on this before making any changes.

Logged In: YES
user_id=116840

IIRC this problem was also reported a few months back, and
was due to a missing package.

The CUPS tests in configure check for the existence of
the "cups-config" program. If cups-config is present,
it /should/ follow that the rest of the CUPS headers and
libraries are present. A distributor in the recent past
did include cups-config in the cups package instead of
the -devel package. This not a good idea, IMHO. In
Debian, it lives in the libcupsys2-dev package.

I just read Klaus' comments, and we can add an additional
check for the headers if needed. However, I am confused
why third-party vendors don't simply use package
dependencies like the rest of us. It would be cleaner for
them to package up their driver properly instead of (I
guess) using an installer script--they are nearly always
flaky (it's "fallback" behaviour is a disgrace--it should
have aborted with an error!).

If cups-config is being (ab)used for things other than
building, moving the building part out to a dedicated tool
like pkg-config (just install a cups.pc) might be a better
move long-term to make detecting CUPS more reliable.

Feel free to pinch src/main/gutenprint.pc.in for this
purpose.

Regards,
Roger

Logged In: YES
user_id=1542465

Roger, I agree with you.
We had cups-config in the cups-devel package for a long
time in the past. But then customers reported back to us,
that they were unable to install a provided filter by a
printer vendor. After a while we noticed that the printer
vendor (ab)used "cups-config" to check for --serverbin.
(I'm sorry, but I cannot remember anymore the name of the
vendor.)

I had a bad feeling either, when moving cups-config from
the cups-devel package into the cups package. But it was
the only solution we can provide so far to fix this filter
issue for the unexperienced user.

I don't know neither, why vendors are doing this way.
Maybe they are to unexperienced with Linux, and had -- due
to a growing market -- to react and provide filters for
their printers suddenly fast. :) Seems that this quick
solution wasn't the best, but we have to address it.

Anyway. I had the following arguing in mind: I expect from
someone, who is able to start a compiler, more experience
than from a person, who just downloads a driver/filter.
Therefore we have to provide an easy possibility to
install them for the unexperienced user, and expect the
more knowledge from the experienced one. Therefore the
later had to know how to solve any such compiler issue (=
install the appropriate cups-devel package).

OTOH, we don't distribute gutenprint as long as there has
no final (stable) version released. This might reflect our
focus on a stable system. I'm neither against developers,
who replace gimp-print by gutenprint in their SUSE system
(but they should keep in mind that they lose the
possibility to ask the SUSE/Novell installation support
for help when doing so). Nevertheless, hopefully they can
send feedback to this project and therefore this project
is soon stable again.

But it might help SUSE and the gutenprint project, if
there is an additional check in the gutenprint configure,
if "cups/cups.h" is present. I think it's NOT A BUG, not
to include any such check, but it might help both of us to
reduce bugzilla entries in the future.