Created attachment 35029 [details]
configure - allow using --enable-cups in Mac OS X

Created attachment 35030 [details]
Changes to psprint to allow compiling --enable-cups

The second patch enables debug messages for some files for testing purposes.

Also, some legacy 10.1 Mac OS X code is removed, as that code is not used by
current Mac OS X systems anymore.

One mutex was moved a bit up in an attempt to fix possible threading issues with
default Mac OS x printing code.

Good catch! And I was wondering why our cups support on MacOs X doesn't work as
good as on Linux ..

Regarding the configure patch: I believe the file to patch is configure.in. The
new configure script is actually generated by autoconf then.

@rene, can you please confirm.

@pl: please have a look at patch 2. Thanks. 

You'll want to remove those definitions for OSL_DEBUG_LEVEL; this way that is
enabled for all platforms. The easiest way to achieve OSL_DEBUG_LEVEL=2 is to
build with "debug=true" on the command line.

There is something i do not understand: if you compile with CUPS_ENABLED, does
the code in cupsmgr.cxx not come into action ? Why is it necessary to change
PrinterInfoManager at all as the work with cups should be done inside the
specialized CUPS PrinterInfoManager (see psprint/source/printer/cupsmgr.cxx) ?
Currently CUPS support is strictly confined to that file.

mox->obr: I think most patches just patch BOTH configure and configure.in... I
was just being lazy about it...

pl: The debug messages are not meant to appear in the final patch. The current
patch is for testing stuff. 

As for cupsmgr, I think the cupsmgr IS used with the patch (have to check
carefully, though). The problems is, that the current MACOSX code _bypasses_
much of the default cups codepaths. Thus, my patch mostly de-bypasses that code
for --enable-cups, so that the default code paths are used again on MACOSX.

Adding myself to CC

obr, pjanik, others: 
could you make a test build with the patch and post it to a website so that
users with printers could test it. I think it would be good to have the debug
messages, that I enable in the patch, set on.

I have tested this with my USB printer, but more testing is needed and I don't
have the equipment...

Trying to update the patch to m165 on Panther, I stumbled over the fact that
Panther does not come with /usr/include/cups/cups.h. I even needs manual
interaction to get this build on Tiger with Panther SDK:

http://lists.apple.com/archives/printing/2005/Dec/msg00035.html

How do we want to proceed ?

Created attachment 36198 [details]
Patch to psprint to use correct library extension

I think we should leave the non-cups printing code paths as they are - we can
probably remove the #ifdef MACOSX sections entirely as soon as we drop support
for panther - however, as I understand it, they wont hurt CUPS support.

After manually copying the cups headers to /usr/include/cups, I was able to
compile and run OOo with CUPS support on Panther with the minimal patch to
psprint that I have attached.

So, should configure advice to download and install the headers manually on
Panther (or to install the corresponding fink/darwinports/etc. package) ? If so,
I would be glad if someone with more experience in configure would jump in ..

Created attachment 36199 [details]
The same patch, but with diff -u

Created attachment 36200 [details]
An even shorter version of the previous patch ;-)

obr: your patch looks nice and simple :) however, even though the OOo compiles
and runs with that patch, I'm not fully confident that the native cups is fully
used. 

Looking at the code in OOo, there seems to be many places, where #ifdef MACOSX
-defines explicitly direct Mac OS X to use different code than other unixes. So,
I think there needs to be several places, where #ifdef MACOSX is changed to #if
defined(MACOSX) && !defined(ENABLE_CUPS). (look at my original patch) 

For other things, I agree that it is not necessary to change the old
(Mac-specific) code. 

As for config_office -stuff, I think the only necessary thing is to make sure
darwin*) -sections have enable_cups=yes (both configure and configure.in). The
current code already checks for cups/cups.h and issues warning if it is not
found. I think that is enough. Mac OS X build instructions on the web can then
specifically inform that building on Panther and --enable-cups, requires
manually adding the headers.

I wish I had more time to work on this stuff, but unfortunately not.

Mox: I was hoping I could get around looking at every #ifdef MACOSX individually
;-). Your patch definitly has at least one or two instances replaced, which
should IMO stay as they are. I will get back to look at all instances.

On the configure part: the error message on panther is:

configure: error: cups/cups.h could not be found. libcupsys2-dev or
cups???-devel missing?

After installing "cups-dev" via fink, I still get the same error message,
because the headers are installed to /sw/include/cups, not in /usr/include/cups.
So at least we need a way to tell configure where to look for cups headers.

> After installing "cups-dev" via fink, I still get the same error message,
> because the headers are installed to /sw/include/cups, not in /usr/include/cups.
> So at least we need a way to tell configure where to look for cups headers.

Yes, this is normal procedure for any fink -library used with OOo (GTK et al.) I
see no need for extra instructions (in code) for the cups case. Including fink
goes like:
export CFLAGS="$CFLAGS -I/sw/include"
export LDFLAGS="$LDFLAGS -L/sw/lib"

Not ready in 2.0.3 time frame :(

> Including fink goes like:
> export CFLAGS="$CFLAGS -I/sw/include"

Actually I think gtk+ et al. are handled by fink's pkgconfig instance, which is
found in PATH. However, I would be fine with the minimal approach.

What do others think ? Is it acceptable to require a manual "export CFLAGS" on
Panther ?

Created attachment 36351 [details]
psprint cleanup

After going through all the #ifdef MACOSX places, I removed all occurances that
seemed to be obsoleted by the move to the CUPS printerinfomanager implementation:
parsing of /etc/cups ppds directly is not what I would expect when using
--disable-cups in configure.

The patch looks very nice, cleans up lot's of stuff. The SAL library naming has
an issue recently filed by pjanik or somebody else. Can't remember the issue
number though...

mox: you probably mean Issue 65011, which is about SAL_MODULENAME_WITH_VERSION.

ericb->obr

What do you think about propose patch Maho for 2.0.3 ?

If needed, I propose to build a installset, and provide this experimental build for tests.

-> ericb:

I am fine with this. However, I could need some help to generate a complete diff
(psprint + config_office), since autoconf 2.57 (Panther) produces a several
hundred lines diff for configure from a single line change in configure.in and
autoconf 2.59 (Tiger) encounters an error >>Can't locate object method "path"
via package "Request" at ..<<.

Or should I go ahead and changing configure (+ configure.in) manually ?

obrmac: change only configure.in, configure can be generated by someone else and
it is re-generated by Hamburg RE on integration anyway.

Created attachment 36428 [details]
Full patch against m168

ericb:
I'd like not to include not integrated patches for
release packages, if it is not a show stopper or build breaker.
and patch itself is not targeted at 2.0.3.

ericb->maho

I have been contacted by several people, for installing from 200 to 600
machines, and printing is obviously a showstopper for them.

Of course, I perfectly understand your point of view, but what is the best ?

ericb-> obr : they are ok to test if everything works in experimental builds
I'll provide them, but official build would be the best may

Just my opinion

obr->ericb: I hope to create a CWS for this (based on m168) this evening. 

If you have the time to do the QA build, provide it to the users for testing and
it fixes their problem, we should declare this a stopper for 2.0.3. I doubt we
could get a better QA for this patch.

If it does not fix their problem, the patch is probably not ready for
integration yet.

ericb->obr 

m168 checkout started : I'll do the build on Panther, and ask for tests.

If it starts this evening (let say 22:30) , the build wont be available for tests before tomorrow afternoon 
~17:00

I'll advertise my testers.

Created attachment 36445 [details]
Patch now quotes CUPS_LIB_NAME correctly.

@ericb: I have commited the patch to CWS macosxcups. Please make sure to
regenerate configure before building. Also compiling and a basic CUPS test on
Linux would probably be appropriate.

obr: please use autoconf 2.59 for regeneration of configure

ericb:
> Of course, I perfectly understand your point of view, but what is the best ?
Please do a thorough tests and convince authorities for integration.                           
currently this patch is even not very well tested. I can provide a build test of course.

maho: as mentioned above, autoconf 2.59 on Tiger fails for me for some reason.
If it works for you, please attach the diff for configure as well.

Created attachment 36466 [details]
regenerated configure script

ericb->obr

Since I build with recent cups headers, it works fine. 

FYI; slopez already reported a success, and will probably confirm here. Waiting for other return (soon).

About code, I just wonder what is the link between CUPS_LIB_NAME and  
SAL_MODULENAME_WITH_VERSION ? I found one in sal/osl/inc/module.h. What is the exact problem ?

Hi,
I've tryed ericb's OpenOffice.org version - [680m169(Build:9026)] - with a HP
PSC 1215 (PSC 121x serie) and it works fine. 
I've made this test with a mac mini with MacOS X 10.4.3 with the printer
connected on usb port.
I'll try if I can with a "network printer" as soon as possible.

@ericb: SAL_MODULENAME_WITH_VERSION expands to libcups.dylib.2 instead of
libcups.2.dylib. Unfortunatly I can not easily change this as there are at least
three places where the macro is used and a bunch or libraries that need to get
renamed to comply to the Apple versioning scheme. See issue 65011.

@slopez: thanks for testing.

ericb->obr

Thank you very much, this is clear now.

FYI, one tester reported a problem :

Don't know wether this is a bad configuration or ..  

Printer : AL-C900, Epson laser 

When printing starts, nothing happens, and after opening the Printer Manager,
the task can be started, but stops in the middle. I'll attach the screenshot of
the error

To know more, I'll ask this tester the ppd file associated to this printer.  

Created attachment 36572 [details]
screenshot or printing error

obr -> ericb: IIRC pstopdffilter is a component of CUPS, so it seems it can not
handle the ps file OOo generates. To know whether this is a regression compared
to the old behavior, please ask whether the tester was able to print to this
printer before and also if (s)he runs Tiger or Panther.

ericb->obr 

I already asked :-)    Waiting for the answer

Hi,

I have tested 680m169(Build:9026) - with 2 printer on my Mac mini PPC MacOS X 10.4.6

Document tested is a Writer document with black and color text + draw with color
and bitmap fill.

HP Photosmart is connected on network
HP 845 C is connected on usb

It works fine.

I have just a little problem : fax printer (HP Photosmart FAX) is normaly
disable on Mac OSX dialog box and it is visible on OOo printer dialog box.

Hi all,

I shall test a Panther/m169 setup with 2 networked HPLJ printers tomorrow. I
haven't got access to the machine until then.

Alex

Tested printing to two different colour networked laser printers, HPLaserjet 
Color 2500 and a HP Color MultiFunction 2840 Printer, using CUPS protocol.

Both printers accept b&w and colour print jobs.

Alex

Verified fixed. A big step forward !

set target to 2.0.4

As a build bit for Panther, please have a look at
http://www.openoffice.org/issues/show_bug.cgi?id=67253

This Issue is 'Verified' and not updated in 1yr+, so Closing.
A Closed Issue is a Happy Issue (TM).

Regards,
Andrew
 
Cleaning-up and Closing old Issues as part of:
~ The Grand Bug Squash, pre v3 ~