eradicating -I/usr/include/ImageMagick

Questions and postings pertaining to the development of ImageMagick, feature enhancements, and ImageMagick internals. ImageMagick source code and algorithms are discussed here. Usage questions which are too arcane for the normal user list should also be posted here.
Post Reply
User avatar
yecril71pl
Posts: 81
Joined: 2011-02-08T11:06:09-07:00
Authentication code: 8675308
Location: Warsaw, Poland
Contact:

eradicating -I/usr/include/ImageMagick

Post 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.
User avatar
magick
Site Admin
Posts: 11064
Joined: 2003-05-31T11:32:55-07:00

Re: eradicating -I/usr/include/ImageMagick

Post 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).
User avatar
yecril71pl
Posts: 81
Joined: 2011-02-08T11:06:09-07:00
Authentication code: 8675308
Location: Warsaw, Poland
Contact:

Re: eradicating -I/usr/include/ImageMagick

Post 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?
Post Reply