octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: merging imread and imwrite


From: Thomas Treichl
Subject: Re: merging imread and imwrite
Date: Fri, 01 Feb 2008 21:45:38 +0100
User-agent: Thunderbird 2.0.0.9 (Macintosh/20071031)

Shai Ayal schrieb:
On Feb 1, 2008 9:53 AM, John W. Eaton <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]