[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnucap-devel] New gnucap development snapshot
From: |
al davis |
Subject: |
Re: [Gnucap-devel] New gnucap development snapshot |
Date: |
Wed, 30 Aug 2006 21:05:25 -0400 |
User-agent: |
KMail/1.9.4 |
Most of this is really to Dan, but here it is for all to see..
On Wednesday 30 August 2006 19:39, al davis wrote:
> 2. Configuration changes. Most of the problems with autoconf
> based installation should be fixed. A few minor issues still
> remain, but should not be noticeable to most users.
This package was built with the old system. "make distcheck"
under autoconf still doesn't do the right thing.
The old build system does run some checks, now including to make
sure the autoconf generated files are up to date.
In the autoconf version, "make distcheck" fails if the modelgen
generated files are not present. So, if I "make" then "make
distcheck" it builds a file, including the generated files. If
I do "make distclean" then "make distcheck" it fails.
The files included here are equivalent to what you get
after "make distclean", without the modelgen generated files.
This is the correct set of files for the distribution.
Except for this issue, the old system and the autoconf system
generate equivalent .tar.gz files.
> 3. The "test" directory is not included. It accounted for
> half if the space when unpacked, can be misleading, and led
> to problems with autoconf, so I left it out.
A few issues here ,,,
First, the entire regression set takes a lot of space ... about
half of the total after unpacking. There are files that differ
only on single values, designed to test particular blocks of
code. The intent is to get 100% code coverage, but it doesn't
quite do that.
Second, I suspect that most users don't know what to do with
them, and how to interpret the results. Some of the tests are
designed as stress tests, with the intent of exposing all
possible issues. Results may be a little different, but it
requires deep understanding to know if the difference matters
or not.
Third, the results directory (which has been named "==") is
fully generated by the test script, usually as something else
and renamed. The "makefile.am" and associated files present a
maintenance problem.
Fourth, I expect this regression suite to grow considerably, to
several times its current size, as Verilog is implemented and
more models are added.
Based on all of this, I think it makes sense to distribute it
separately.
There is a serious need for a bunch of tests that can be used as
user tests and as tutorials.
> 4. The "man/html" directory is not included, due to problems
> with autoconf.
This is strictly an autoconf issue. The whole directory is
generated, and will not be if you don't ask for the html
manual. Autoconf requires some files which must be manually
maintained, or the "make html" needs to generate them,
even "Makefile.am", and therefore "Makefile.in".
> 5. If you use the old build system, you can build "info" and
> plain text versions of the manual. Use "configure.old" to
> use the old build system.
I just didn't migrate the changes over. The "info" directory
has the same issues as the "html" directory. These use hevea
to make them.
Also ...
I decided not to include gnucap-man.dvi. Gnu policy says to
include info, nothing else, but I disagree. "dvi" is a ready
to print version. It seems to me that "html" accomplishes all
that "info" was supposed to do, but is more general.
Regarding the issue under #2 ... I insist that the modelgen
generated files should not be included. Any user can build
modelgen, and make those files. The process of building the
program should put them with the .o files. This is done
correctly with either system.
One point seems a little strange is when the modelgen generated
files are made. In the old system, they are deferred until
needed. With the autoconf system, they are all built before
any .cc files are compiled. This doesn't really matter, except
that I don't understand why they should be different.
In a future release, these files will not be linked at build
time, but supplied separately to be linked at run time. This
will enable users to add models without recompiling the whole
simulator.