[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
- Re: getstruct, setstruct, etc., (continued)
- Re: getstruct, setstruct, etc., Paul Kienzle, 2004/07/21
- Re: getstruct, setstruct, etc., Andy Adler, 2004/07/22
- Re: getstruct, setstruct, etc., Paul Kienzle, 2004/07/22
- Re: getstruct, setstruct, etc., Andy Adler, 2004/07/22
- Re: getstruct, setstruct, etc., Paul Kienzle, 2004/07/22
- Re: getstruct, setstruct, etc., Etienne Grossmann, 2004/07/22
- Re: getstruct, setstruct, etc., Paul Kienzle, 2004/07/22
- Re: getstruct, setstruct, etc., Etienne Grossmann, 2004/07/23
Re: getstruct, setstruct, etc., David Bateman, 2004/07/23