Page 1 of 1

eradicating -I/usr/include/ImageMagick

Posted: 2011-03-30T10:32:43-07:00
by yecril71pl
The ImageMagick library build process, as well as the C language interface available for the client code, depend on the ImageMagick directory being in the include header search path.  We view this requirement as inessential noise and we intend to eradicate it.  That is, in addition to the currently recommended client code syntax [1] the replacement syntax [2] should work and the directive [3] in the implementation code should be replaced with [4].

Code: Select all

/* 1 */
#include <wand/MagickWand.h> 
/* 2 */ 
#include <ImageMagick/wand.h>
/* 3 */
#include <magick/whatever.h>
/* 4 */
#include "../magick/whatever.h"
Old code requiring the extended header path should work without modification.

Re: eradicating -I/usr/include/ImageMagick

Posted: 2011-03-30T11:49:11-07:00
by magick
When ImageMagick 7.0 comes out we're changing ImageMagick/magick to ImageMagick/MagickCore and ImageMagick/wand to ImageMagick/MagickWand to better reflect the API. However, using ImageMagick as a prefix may not be an optimal solution. It prevents us from using version information in the future. For example GTK coexists /usr/include/gtk-2.0 with /usr/include/gtk-3.0 and the -I is required to point to the right path (e.g. -I/usr/include/gtk-3.0).

Re: eradicating -I/usr/include/ImageMagick

Posted: 2011-03-30T15:07:44-07:00
by yecril71pl
There actually two scenarios that must be covered; the situation resembles that of side-by-side shared libraries.

General setup (with obvious abbreviations for brevity)

/u/i/IM/wand.h:

Code: Select all

#include "../ImageMagick-7/wand.h"
/u/i/IM-7/wand.h:

Code: Select all

#include "wand/MagickWand.h"
/u/i/IM-6/wand.h:

Code: Select all

#include "wand/MagickWand.h"

  • The client wants to use the current API:

    Code: Select all

    #include <ImageMagick/wand.h>
    
  • The client wants to use a specific API:

    Code: Select all

    #include <ImageMagick-6/wand.h>
    
These directives can be in the client’s standard affix, so there is no need to change them in all source files should the client developer changes her mind. Since such code would be tightly bound to the API, it actually makes more sense to specify the version in the sources (as opposed to the build system configuration).

And changing [3] to [4], which is the change I am really after, will not hurt anybody. On the contrary, it will make the code structure more robust.
Would you care to drop me a note regarding this patch? as of 6.6.9-8, the patch seems partly applied. In which part?