Re: gEDA-dev: What should be included in the dist file?

[al davis <ad106-at-NOSPAMfreeelectron_dot_net>]

On Wednesday 16 August 2006 22:09, Dan McMahill wrote:
> Stuart Brorson wrote:
> > Al --
> >
> > Sorry for my late response.  Answering you was on my ToDo
> > list, but somehow went down a rathole.
> >
> >
> >
> > 0.0  Tex, Latex, or texi files if you already have them. 
> > Why not distribute them?  Just don't make the build
> > dependent upon having the build tools.  Build them only
> > when --enable-maintainer-mode is set during configure.
>
> or only build them when they are out of date and if they are
> included in the distfile and only removed with a 'make
> maintainer-clean', then the same effect can be achieved.

These are the editable source files, therefore are required 
under GPL.  My question was about generated files that are 
included for convenience.

> >> 2. DVI files?
> >
> > Why?  This is generated from .tex, and is only used to
> > generate ps and pdf.  At one time you sent this file to a
> > printer, but that was back when I was a grad student, i.e.
> > a loooooong time ago, when dinosaurs roamed the earth.
> >
> > It's just an intermediate file format, generated on the way
> > from .tex to .pdf.  Therefore, I think you should not
> > distribute dvi.
>
> other than distributing it keeps the dependency chain intact.
>  Also it means if a user wants to modify the manual, s/he
> doesn't need to do anything special (other than have latex
> and friends installed) for it to "just work".

Having the dvi file there could confuse make.  Suppose somehow 
the dates got munged.  Make builds the pdf from the dvi, 
ignoring your newly edited source.  My preference is to leave 
it out, because it is neither the desired target nor source.

dvi files are used a lot more than you might think.  It's not 
just TeX.  Several markup languages use it as an intermediary.


> Despite the warts that autoconf/automake have, I really think
> they make life easier for the end user provided some care
> went in to the setup especially with regards to the docs.
>
> Part of why I put together the autoconf/automake system for
> gnucap is I was tired of dealing with the old system while
> maintaining the NetBSD package.

The old system was never designed to handle the installation 
issues that autoconf does.  It was never designed for fully 
automated installation.  It was a hack to solve some pressing 
issues at the time, which was about 20 years ago.  It was not 
designed to last 20 years, or even 5 years.

On the other hand, autoconf falls significantly short as a 
development environment.  It imposes a lot of overhead.  In the 
development phase, it seems like a makefile obfuscator.  I can 
handle makefiles fine, but now I need to figure out what to 
feed the extra gadgets to get the makefile I want.  Some of the 
configuration aids supplied with Linux distributions are the 
same.  They help if  you want to do what they want you to do.  
Otherwise they get in the way.

I think the problem is an attitude that if there is a wrapper 
program, ugliness that is hidden doesn't matter.  I would 
rather pay attention to the hidden, so the wrapper program 
should be able to be used as a teaching aid, to teach what is 
underneath.

So, I agree that the distribution package must use it, until 
something better comes along, but I still need something more 
raw for development.  That better program that will replace 
autoconf absolutely needs to have an autoconf 
compatible "configure", with all the same options, and it needs 
to generate a finished makefile, with all the same targets.
It needs to do it with only the "basic tools".

It has crossed my mind to do it, but I would rather work on 
gnucap.


_______________________________________________
geda-dev mailing list
geda-dev@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev