octave-maintainers
[Top][All Lists]
Advanced

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

Re: getstruct, setstruct, etc.


From: David Bateman
Subject: Re: getstruct, setstruct, etc.
Date: Fri, 23 Jul 2004 11:34:45 +0200
User-agent: Mutt/1.4.1i

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).

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.

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?

Cheers
David

-- 
David Bateman                                address@hidden
Motorola CRM                                 +33 1 69 35 48 04 (Ph) 
Parc Les Algorithmes, Commune de St Aubin    +33 1 69 35 77 01 (Fax) 
91193 Gif-Sur-Yvette FRANCE

The information contained in this communication has been classified as: 

[x] General Business Information 
[ ] Motorola Internal Use Only 
[ ] Motorola Confidential Proprietary



reply via email to

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