octave-maintainers
[Top][All Lists]
Advanced

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

Re: getstruct, setstruct, etc.


From: Paul Kienzle
Subject: Re: getstruct, setstruct, etc.
Date: Fri, 23 Jul 2004 10:00:55 -0400


On Jul 23, 2004, at 5:34 AM, David Bateman wrote:

Paul,

It would be nice to have a deprecated directory, and a set of
tests in configure.add of the form, e.g.,

        OCTAVE_EVAL([exist('struct')>0],OCTAVE_HAVE_STRUCT)

a Makeconf.add which has, e.g.,

        OCTAVE_HAVE_STRUCT= at OCTAVE_HAVE_STRUCT@

and Makefile which has, e.g.,

        TARGETS=
        ifeq ($(OCTAVE_HAVE_STRUCT),0)
                TARGETS=$(TARGETS) struct.oct
        endif


This is a bit heavy, as every target would depend on a particular test
in the configuration. Basically we know which versions of octave depreciated certain files and we can simplify all of the depreciated tests to one that
just checks the version numbers.

I already implemented something like this for FIXES/sort.cc which is in the
octave CVS, where in the Makefile I did

t2.1.58=sort.oct
SORT_BUILD=$($(word 2, $(sort t$(OCTAVE_VERSION) t2.1.58)))
TARGETS = $(TARGETS) $(SORT_BUILD)

In this way I didn't need a configure.add or Makeconf.add file and the
choice of whether to build is based purely on the sorted order of the
octave version relative to a preselected version (Here 2.1.58).

Yeah I saw this.  Great hack!

I was being lazy and not wanting to figure out which version of
octave things appear and disappear.  You are right, though, that
this is a better approach.  Particularly since my test fails if
octave-forge is already installed into system paths.

In any case, this problem is likely to come up quite often and a consistent
way to treat it is probably a good idea. In fact the rule

        %.m: %.m.in ; $(CP) $< $@

should probably be part of Makeconf.base, then the above scheme might be
adapated to have something like

t2.1.50=foo2_1_50.m bar2_1_50.oct
t2.1.57=foo2_1_57.m
TARGETS2_1_50=$($(word 2, $(sort t$(OCTAVE_VERSION) t2.1.50)))
TARGETS2_1_57=$($(word 2, $(sort t$(OCTAVE_VERSION) t2.1.57)))
TARGETS = $(TARGETS) $(TARGETS2_1_50) $(TARGETS2_1_57)

Where foo2_1_50.m and foo2_1_57.m are built from foo2_1_50.m.in and
foo2_1_57.m.in, and bar2_1_50.oct is built or not from bar2_1_50.cc.

Rather than having a different m-file for each version, I would
rather have a simple preprocessor which accepts a version number.
I'm not sure if this is better done as a load-time feature (i.e., if it is part of octave), or a build time feature. Either way it's a separate problem.

This seems to me to be pretty generic and the minimum of additional
work to maintain. The only issue is then where do the depreciated
files live? For example sort.cc still lives in FIXES. But maybe each
directory should have a depreciated directory where such files exist,
or should we have a single directory in the root for depreciated files?
Or maybe a combination of both?

In the spirit of independent packages the deprecated files should
continue to live in the usual directory.

On the other hand, in the spirit of full disclosure functions which
modify octave behaviour should be isolated in FIXES.

- Paul



reply via email to

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