From: Etienne G. <et...@an...> - 2001-02-12 19:58:14
|
Hello, From: "Matthew W. Roberts" <ma...@ne...> # I know this is a bit old... # # > > One more thing -- are we still planning on setting up a separate # > > matcompat directory? I'd like to upload Paul Kienzle's scripts into # > > the repository. # > # > I wouldn't use a separate subdirectory, we should merge the files in our # > directory structure. # # The problem with this is that when a new version of matcompat is # released (as just happened last month) we have to go back and figure # out again where we put the files. # # > If we want to release a matcompat package we can use some Makefile magic # > to bundle the appropriate files. # # Sure, but it seems that it would be a lot easier to just keep them # in a separate directory. # # > Have you talked with Paul about that? # # No, but I will contact him. I was writing a paper lately and the first question was : "what are the claims?" Once this is settled things are straightforward. What are the claim of the Sourceforge Octave repository?I feel it is caught between the Octave distro and individual developers. How should a endish-user look at it? The official distro is stable and installs through 'make install', or by installing a binary package. Functions are accessible through the command line, doc through html/texi/ps. This way of installing is simple to understand. Individual developers produce extra m-files, .cc files, patches, usually without a Makefile or any installation procedure. In the best of case, the user just puts the m-files within his LOADPATH. Otherwise, he produces a .oct file and puts it within LOADPATH (right?). Or else, patches the source octave tree and re-does "make install". This requires more work from the user. One possible claim could be : "Allow end-users to get a desired functionality easily". Another could be "Provide links / archive of all contributed octave development". Or is it something else? Cheers, Etienne |