[argyllcms] Re: ArgyllCMS build system

Gerhard Fuernkranz wrote:

> Graeme Gill wrote:
>> I'm under the impression that there aren't currently great
>> differences between Argyll and what lprof is using. I think
>> they're currently tracking my releases reasonably closely.
>> I'm happy to make any minor changes to ease the tracking.

For the most part the changes made to the ArgyllCMS code by LProf are small 
and fairly trivial.   All of the places were there are changes have been 
documented in LProf CVS (as required by GPLv3) and these are limited to 8 
files.  I would be happy to get details of these mods to Graeme so that he 
can either modfiy his code so that the mods are not nessesary or he can let 
me know if there is a better way to handle these issues.

The biggest single mod is related to differences in the UI between LProf and 
ArgyllCMS and how this impacts error handling.  That is, it is sort of OK to 
dump users out to a command prompt on an error in a CLI program but not a GUI 
app.  So I have modified numsup.c to allow LProf to trap errors to prevent 
this from happening.  A more generalized fix to this issue would likely 
involve a significant amount of work but if Graeme is working on a non-GPL 
GUI version he will need to do this at some point in any case.

Most of the other mods are small.  One set is related to a Qt naming conflict 
and most of the others are related to decoupling the code or preventing 
compile errors in the LProf build environment.   It only takes me a few hours 
to mod a new version of the code when there is a ArgyllCMS release.   

Graeme - I will sent you a list of mods off list in the next few days.  And if 
any of these can be fixed so that LProf does not have to mod the code then 
that makes me a happy camper and I would be even happier if I did not have to 
mod the code at all. 

> IMO one of the major problems is that the various Argyll libraries seem
> to be considered "internal interfaces" only. These interfaces are not
> stable and may change with each new version of Argyll, and they are
> obviously neither guaranteed to be ABI nor API compatible with the
> previous versions. So there will always be a strict 1:1 version
> dependency between Argyll and a particular application (like lprof)
> which uses Argyll libraries, and different applications may require
> different versions of Argyll as prerequisite. 

This is the main issue.   I am not sure if this will always be true but I 
don't expect it to change any time soon.

> I see the following ways to address this:

> 1) each application continues to include its own copy of the required
> Argyll modules and links them statically (as lprof currently does)

> 2) or the Linux distributions must provide multi-instance capable
> packages for Argyll, so that several version of Argyll can be installed
> on the system at the same time, as prerequisites for different Argyll
> applications which require a different version of Argyll as prerequisite.

I am not sure how feasable this is.  One other issue is that because the 
ArgyllCMS libraries are "internal interfaces" it is difficult to identify and 
isolate what is in fact a logical library unit (IE. a unit that only 
implements a specific set of functionality).  

In addition the libraries and the ArgyllCMS applications that use them are 
often very tightly coupled and it is not uncommon when inspecting the 
ArgyllCMS code to find that the API for a given set of functionality is 
spread between the "library" and the actual applications or spread across 
what should be several discreet libraries.  The error handling routines in 
numlib.c is one example (there are even comments in the code saying it should 
be seperated out).

> 3) or future Argyll version would need to provide library interfaces
> which are strictly backwards compatible (API, but also ABI, due to
> shared libraries) with previous versions. But IMO this is likely a big
> restriction for Graeme, as it may prevents flexible design changes (I
> understand that there were good reasons for all incompatible changes
> which happened in the past).

I think that the ArgyllCMS code needs to mature significantly before it even 
becomes feasable for Graeme to consider this.

> Regards,
> Gerhard

Digikam currently uses a forked version of the base LProf library.  I suspect 
that they forked it back during the time when LProf was an orphan and that 
they have not gotten around to seperating it back out.  Currently LProf 
statically links this library but it is API stable at this point and it would 
be a simple matter to make it a shared library that could be used by other 
applications such as Digikam.  I think that the Digikam fork of this code may 
be significantly different from the library curretly being used by LProf 
since we have added new functionality but I suspect that the specific calls 
they are using are likely unchanged and that it would require very little 
work for them to use a shared version of this library.

LProf CVS currently contains a forked version of LCMS as well.  I have offered 
to help Marti integrate the changes in the fork back into LCMS but I don't 
expect this to happen any time soon.  This change is non-trivial but involves 
functionality that would only be used by profiling software.   At some point 
I would like to figure out how to seperate this functionality from LCMS but I 
suspect that LCMS would still need some mods to make this possible but if 
this were possible it would allow LProf and other apps to create tags that 
are unsupported by the LCMS library.

Hal

Other related posts: