merging imread and imwrite

[Thomas Treichl]

Shai Ayal schrieb:
> On Feb 1, 2008 9:53 AM, John W. Eaton <jwe at bevo.che.wisc.edu> wrote:
>> On  1-Feb-2008, Shai Ayal wrote:
>>
>> | I'm not exactly sure how dynamic linking works, but is there no way to
>> | add this to octave such that if someone does not use imread/imwrite
>> | then the libraries don't get loaded to memory?
>>
>> We can do this by just linking the Magick++ library to the
>> imread/imwrite/etc. .oct files and not to Octave itself.  This is
>> currently the way we handle several other libraries.  For example, see
>> the following lines in src/Makefile.in:
>>
>>   ifeq ($(ENABLE_DYNAMIC_LINKING), true)
>>     ifdef CXXPICFLAG
>>       convhulln.oct : pic/convhulln.o octave$(EXEEXT)
>>             $(DL_LD) $(DL_LDFLAGS) -o $@ $< $(OCT_LINK_DEPS) $(QHULL_LIBS)
>>       __delaunayn__.oct : pic/__delaunayn__.o octave$(EXEEXT)
>>             $(DL_LD) $(DL_LDFLAGS) -o $@ $< $(OCT_LINK_DEPS) $(QHULL_LIBS)
>>       __voronoi__.oct : pic/__voronoi__.o octave$(EXEEXT)
>>             $(DL_LD) $(DL_LDFLAGS) -o $@ $< $(OCT_LINK_DEPS) $(QHULL_LIBS)
>>       regexp.oct : pic/regexp.o octave$(EXEEXT)
>>             $(DL_LD) $(DL_LDFLAGS) -o $@ $< $(OCT_LINK_DEPS) $(REGEX_LIBS)
>>       urlwrite.oct : pic/urlwrite.o octave$(EXEEXT)
>>             $(DL_LD) $(DL_LDFLAGS) -o $@ $< $(OCT_LINK_DEPS) $(CURL_LIBS)
>>       __glpk__.oct : pic/__glpk__.o octave$(EXEEXT)
>>             $(DL_LD) $(DL_LDFLAGS) -o $@ $< $(OCT_LINK_DEPS) $(GLPK_LIBS)
>>     else
>>       ...
>>     endif
>>   endif
>>
>> The $(QHULL_LIBS), $(REGEX_LIBS), $(CURL_LIBS), and $(GPLK_LIBS)
>> should not be linked to Octave itself, or
>> liboctinterp/liboctave/libcruft.
>>
> well, it looks like a good compromise -- those needing the
> functionality will be happy to pay the (memory) price for
> imread/imwrite, while others will not pay anything.
> The only problem is then for packagers who want to provide a complete
> octave distribution, which will now have to provide the new library/

Adding another library to the scripts that run in the background and that are 
used for building eg. Octave.app is not so hard - it just needs some time until 
finished. When this has been done the automation procedure can also be used for 
the following releases without big modifications. And it doesn't matter if 
machine compiles 3h or 4h while I'm sleeping ;) That's ok.

However, I still think that all backends of ImageMagick are not needed for an 
standalone Octave pack and some compromise about which backend should be added 
and which one should be left away must be done (eg. ?jbig, lcms, lqr, openexr? - 
I actually have never heard of them before - are they needed?)...

   Thomas