Re: New gnucap development snapshot

al davis wrote:
> On Sunday 09 July 2006 17:47, Dan McMahill wrote:
> 
>>al davis wrote:
>>
>>>There is a new development snapshot of gnucap available.
>>>
>>>
>>>
>>>You can get it at:
>>>Official site:
>>>http://www.gnucap.org/devel/gnucap-2006-07-08.tar.gz
>>>Mirrors:
>>>http://www.geda.seul.org/dist/gnucap-2006-07-08.tar.gz
>>
>>cool.  I was updating the NetBSD package and ran into 3 minor
>>things that I'm somewhat puzzled by.
>>
>>Did you do anything to the tar file after running 'make
>>dist'? 
> 
> 
> This is a transitional release.  The tar file was actually made 
> by the old system.  The new system didn't work correctly, and 
> rather than taking the time to troubleshoot, I fell back to the 
> old.
>
> Actually, I spent quite a bit of time troubleshooting in 
> general.  I don't yet fully understand what the issues are.

ah.  That would explain what I saw.  I'd be happy to help troubleshoot 
the other issues.

> 
>>I'm asking because the man/gnucap-man.dvi file 
>>doesn't seem to be in the tar file but as near as I can tell
>>from man/Makefile.am, it should be.  
> 
> 
> It wasn't in the old dist file.  I consider it to 
> be "non-source" and those who don't have TeX installed can't 
> use it anyway.  It is an intermediate file.

My thinking in including it in the distfile is that since it is in the 
dependency chain (gnucap-man.tex -> gnucap-man.dvi -> gnucap-man.pdf) 
the build system will want to build it to produce an up to date 
gnucap-man.pdf and html man pages.  I do agree it is non-source, but it 
is at least machine independent.


>>The result is 'make 
>>install' fails if I don't have latex installed (the build
>>system is set up to use latex if found but otherwise issue
>>warnings and use the .dvi file which ships in the .tar.gz).
> 
> 
> Maybe that explains some of the behavior I was seeing.  The 
> system I use mostly las latex installed.

same here but probably not everyone has/needs/wants latex to be installed.


>>The second question is if your intention is to not have the
>>html manual installed with 'make install'.  By commenting out
>>the SUBDIRS= html line in man/Makefile.am, the html manual
>>doesn't get installed.  Whats wierd is by commenting that
>>out, the html manual shouldn't have even ended up in the
>>.tar.gz file yet I see it there.
> 
> 
> As I said, the tar.gz file was made the old way, which does 
> include the html manual.  Even though it is non-source, for 
> many users, it is a preferred way to view the docs.  Both html 
> and pdf are provided, so you can read the manual right away 
> without building anything.  Should this be changed?  I wonder, 
> because both of these are non-source.
> 

I don't have a problem distributing generated files when they are ready 
for use.  In other words the .pdf manual is useful right away.  And its 
not like the real sources are not distributed too.  At least for me, it 
seems like the best of both worlds.  You have the real sources and if 
you modify them, the generated files will be rebuilt but if you don't 
have latex, dvipdfm, and hevea you're not prevented from having a 
formatted manual.

> 
>>My last question is really an observation that
>>test/==/Makefile.in seems to have been generated by a really
>>old automake (1.4) while all the others are from a modern
>>(1.9.6) automake.  I'm not sure how this one got singled out.
> 
> 
> So that explains it ......
> 
> That whole directory is generated.  Same goes for man/html.  So, 
> when tinkering, I might remove it then rebuild.  The rebuild 
> didn't put in Makefile.am, so Makefile.in wasn't there either, 
> so I put it in manually.

ahh.

> I have a lot to say about this snapshot.  Mostly it is about the 
> new time step control.  Prepare for some reading!  

Does this mean a paper is coming down the pipe or just a good section in 
the manual?

Let me know if there are any specific build system issues you'd like me 
to try and address.

-Dan