Re: [Axiom-developer] version control

[Gabriel Dos Reis]

root <address@hidden> writes:

| | > The crucial difference is the first step.  The distribution tarball
| | > need not contain only source files that come from the CVS/TLA/SVN repo.
| 
| > If you want to test what the distribution should be/work then say "make
| > distcheck" instead of simple "make", but you did not answer that
| > question :-) 
| 
| i have no idea what a 'distcheck' could mean.

>From "info Automake":

 # Automake also generates a `distcheck' rule which can be of help to
 # ensure that a given distribution will actually work.  `distcheck' makes
 # a distribution, then tries to do a `VPATH' build, run the test suite,
 # and finally make another tarfile to ensure the distribution is
 # self-contained.
 #
 #    Building the package involves running `./configure'.  If you need to
 # supply additional flags to `configure', define them in the
 # `DISTCHECK_CONFIGURE_FLAGS' variable, either in your top-level
 # `Makefile.am', or on the command line when invoking `make'.
 #
 #    If the `distcheck-hook' rule is defined in your top-level
 # `Makefile.am', then it will be invoked by `distcheck' after the new
 # distribution has been unpacked, but before the unpacked copy is
 # configured and built.  Your `distcheck-hook' can do almost anything,
 # though as always caution is advised.  Generally this hook is used to
 # check for potential distribution errors not caught by the standard
 # mechanism.  Note that `distcheck-hook' as well as
 # `DISTCHECK_CONFIGURE_FLAGS' are not honored in a subpackage
 # `Makefile.am', but the `DISTCHECK_CONFIGURE_FLAGS' are passed down to
 # the `configure' script of the subpackage.


Granted we don't use Automake, *but* we can have a Makefile rule that
does exactly that check.  

| so only programming language code goes in the CVS?

No.

| what about the documentation?
| what if the documentation is hyperlinked?
| what if the documentation is dynamically constructed?
| what if the documentation is in video?
| how do you do versioning without a CVS?
| how do you do coordinated development without using CVS?
| WHY do coordinated development WITHOUT using CVS?
| 
| if the non-programming language files reside elsewhere
| who holds these 'master files' that make up a distribution?

I don't think I'm saying all documentations have to reside elsewhere.
Furthermore, I don't think I've said hyperlinked documentation should
reside elsewhere.  I disput the notion that everything Axiom needs to
run must reside in Axiom repo.  I hope you do not propose to retain
packages of Linux kernels in the Axiom repo, because Axiom would need
running Linux, therefore it must encure that the repo must ensure that
it has copies of it.

| how did axiom suddenly change from a project into a 'distribution'?

I don't think I've suggested that Axiom should change from project to
distribution.  

However, there is always the question of how you attract new people to
the project.  You have to think about it.  Rigidity is not, IMHO, a
good strategy.  I highly it will not help in reduce people's
skepticism about Axiom.

| what exactly is your definition of a distribution and how does it
| differ from the current system?

I'm not into distribution (even when considering GCC).  However, I do
believe that the project would be meaningful *if* it had users.  Do
you consider feedback uninteresting?

| so my answer to YOUR question is that *I* believe that the CVS is the
| correct place to store the project files.... ALL the project files. 
| so they can be versioned. so we can recreate the video from last year. 
| so multiple people can coordinate building documentation.
| so anyone can build a complete system from the CVS. 
| 
| this is why we use a code versioning system at all.
| otherwise lets just put tarballs on the wiki.
| 
| 
| 
| > I believe I carefully answered:  I believe the steps are broken
| > because the first one.
| 
| so, i repeat *MY* question. Assume the first step happens:
| 
| 
|  1) what kind of final product do you expect when you do:
| 
|  cvs co ... axiom
|  cd axiom
|  ./configure
|  make
|  make install
|  axiom

It depends on what you set up, as *developer*.  

For example, if you don't have GCL installed, the above will fail.
Similarly, it you don't have noweb, it will fail.

Now. Consider this:

  (1) If you're developer, you do the following to make available
      Axiom for users

    svn co ....
    ./configure && make distckeck
    copy the tarball over to a place people can download
   

  (2) If you're Axiom user (not actively developing Axiom), you do the
      following 

     untar the tarball
     ./configure && make && make install
     enjoy Axiom

  (3)  If you're users interested in "playing" with Axiom from SVN repo,
       you're expected to have an environment that meets some minimal
       requirements (e.g. having noweb, GCL, ...).


Bottom line: I would like to see GCL, nowed, etc. tarballs disappear from
Axiom repo.  They are better handled as separate tools and Axiom
should should not be in business in developing its own version of them.

-- Gaby