[cups] how to work around API changes?

Michael Sweet msweet at apple.com
Mon Aug 31 06:56:28 PDT 2015


David,

We always recommend the most recent production release of CUPS as the most stable and up-to-date.


> On Aug 31, 2015, at 9:47 AM, Collins, David <DavidD.Collins at irco.com> wrote:
> 
> Hi Mike,
> 
> If we are just using basic cups printing and haven't developed any api's is 2.0.4 stable and reliable compared to 1.4.2 ?  We are trying to make sure our environment has the latest patches in our large printing environment.
> 
> Thanks
> David
> 
> 
> -----Original Message-----
> From: cups-bounces at cups.org [mailto:cups-bounces at cups.org] On Behalf Of Michael Sweet
> Sent: Monday, August 31, 2015 6:10 AM
> To: The CUPS user discussion list.
> Subject: Re: [cups] how to work around API changes?
> 
> Jacob,
> 
>> On Aug 28, 2015, at 8:25 PM, Jacob Marble <jacobmarble at google.com> wrote:
>> 
>> Context:
>> The following change makes API changes, so my software has to support <1.6
>> or >=1.6, but can't support both.
>> STR #3928 Add accessors for IPP APIs and make IPP structures private.
>> 
>> I need to support users who are building against older CUPS client APIs.
>> The easy way is to copy the new accessor functions into my project
>> (surrounded with #ifndef _CUPS_API_1_6), but that's a legal gray area.
>> 
>> Is there a commonly-accepted way to do this?
> 
> The recommended "fix" for code like this is to define the following before including any CUPS headers:
> 
>    #define _IPP_PRIVATE_STRUCTURES
> 
> This has been in place since CUPS 1.6, and will likely remain in place for a while - our goal is not to make major changes to those structures (very unlikely) but to a) make it easier to access attribute values and b) make it safer to access attribute values.
> 
> As for importing the functions from the newer CUPS releases, that is NOT recommended since you'll end up with duplicate symbols when running the binary on newer systems, which can lead to unpredictable results when your code is in a shared library/loadable module.
> 
> If you want to move the code to the new accessor functions, you can define macros that stand in for the functions on older CUPS releases, and/or include renamed accessor functions.
> 
> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
> 
> _______________________________________________
> cups mailing list
> cups at cups.org
> https://www.cups.org/mailman/listinfo/cups
> 
> ________________________________
> 
> The information contained in this message is privileged and intended only for the recipients named. If the reader is not a representative of the intended recipient, any review, dissemination or copying of this message or the information it contains is prohibited. If you have received this message in error, please immediately notify the sender, and delete the original message and attachments.
> _______________________________________________
> cups mailing list
> cups at cups.org
> https://www.cups.org/mailman/listinfo/cups

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair




More information about the cups mailing list