gnucap-devel
[Top][All Lists]
Advanced

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




reply via email to

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