In article <3e4b6410@news.povray.org> , Thomas Willhalm 
<tho### [at] uni-konstanzde>  wrote:

> If I understand Nicolas' intention correctly, the point is that he wants
> a unified archive, so that everything is included for every platform.
> As a result person A can write a patched version of - say - Linux
> and person B can compile it on Windows -- hopefully without fiddling
> in the sources.

Actually, this is a problem with the current Unix sources which mix Unix and
generic source code in the same directory (level), which will be addressed
in the future.  Neither the Mac nor the Windows archives do this.

> As for the libraries I agree with you. They do not really belong to
> the source code of povray. I would suggest to move them outside the povray
> package and provide separate archives.

No, that would be wrong because that way nobody can reproduce what we did.
Also Linux frequently comes with those libraries in the default install,
this by no means implies everybody gets them this way.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

"Thorsten Froehlich" <tho### [at] trfde> wrote:
>
> >> If that is indeed the suggestion, it wouldn't work because certain
platform
> >> require files in a certain format (line-endings, multiple forks, etc)
that
> >> would not be portable anyway.
> >
> >  Not if you provide the source in different archive formats (see my
answer
> > to Christoph): zip AND tar.gz for instance.
>
> But that still renders sources archived with some formats unusabled on
some
> platforms.  Thus it doesn't make any sense.

IMHO that does make *some* sense... IIRC, zip archives do have a notion of
'text' (vs. binary) files. So, properly done, zip decompressor should be
able to produce platform-specific source (== text, honoring platform's CR/LF
convention etc.) files on each given platform -- from a *single* archive.

Post a reply to this message

"Thomas Willhalm" <tho### [at] uni-konstanzde> wrote:

> As for the libraries I agree with you. They do not really belong to
> the source code of povray. I would suggest to move them outside the
> povray package and provide separate archives.

Oh, no... have mercy! I have had enough nightmare compiling various Linux
sources for Cygwin. As to the way they try (!) to link to external
libraries -- unbelievable mess... (requiring specific minor versions;
libraries requiring other libraries etc.)

> However, as the POV-Team does not support an open development,
> things like that are unlikely to happen.

As to the support of an open development model, you're probably right. But I
believe that that is completely unrelated to the way POV-Ray handles
libraries (the right way, IMHO).

Post a reply to this message

In article <3e4c03b1@news.povray.org>,
 "Vadim Sytnikov" <syt### [at] rucom> wrote:

> IMHO that does make *some* sense... IIRC, zip archives do have a notion of
> 'text' (vs. binary) files. So, properly done, zip decompressor should be
> able to produce platform-specific source (== text, honoring platform's CR/LF
> convention etc.) files on each given platform -- from a *single* archive.

That only solves one problem, line endings in text files. And you have 
to find or write some software that can take care of it.

Even if you could find an archive format that would safely store 
everything necessary (maybe by storing sub-archives in a system 
dependant format), it would mean longer downloads for everybody and more 
bandwidth consumption for the server, and would only be of slight 
benefit to very few people.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

> If I understand Nicolas' intention correctly, the point is that he wants
> a unified archive, so that everything is included for every platform.
> As a result person A can write a patched version of - say - Linux
> and person B can compile it on Windows -- hopefully without fiddling 
> in the sources.

	Your understanding is right, even if it's not something that
I "want", but simply that I would like to discuss here.
	(I should write more clearly what I mean; maybe I'm simply
not sure of my own thoughts  ;-) )

> As for the libraries I agree with you. They do not really belong to
> the source code of povray. I would suggest to move them outside the povray
> package and provide separate archives.

	In principle I would agree, but in practice, for easy installations
I would actually choose to include the supporting libraries in all distributions
(or the unique one if everything is unified). If your system has better/newer
libraries, you can use them. If however one or more library are missing, just
use the one provided with the sources. In the unix configure file that I'm
rewritting, this decision could be made automatically.

	- NC

Post a reply to this message

> IMHO that does make *some* sense... IIRC, zip archives do have a notion of
> 'text' (vs. binary) files. So, properly done, zip decompressor should be
> able to produce platform-specific source (== text, honoring platform's CR/LF
> convention etc.) files on each given platform -- from a *single* archive.

	Yes.

	Just my experience: windows files compressed by WinZip (under windows
machine) can be correctly unpacked under unices/linux with some unzip tool.
And a .tar.gz file created under Linux will be unpacked correctly under Windows
with WinZip or WinRar. CR/LF is thus correctly handled. It means added or
discarded when necessary. This is not true for single untared files of course.
	Look what kind of files are hosted in the thousands open-projects at
sourceforge.net. I think lots of people would be wounded if it didn't work
this way.

	I have no idea how other architectures (mac in particular) would behave,
because I never used them (or maybe only once...). I guess in principle it's
the same story (does mac's 'fetch' handle that automatically ?).

	- NC

Post a reply to this message

> dependant format), it would mean longer downloads for everybody and more 
> bandwidth consumption for the server, and would only be of slight 
> benefit to very few people.

	Have you seen the filesizes of the povray sources ? Currently it's:
- windows source code: 4.5 MB
- mac source code: 3.4 MB
- unix source code: 6.5 MB

	Wow, so UNIX is quite a looser here.
	Now let's detail two of the packages, windows source code and unix
source code. Both can be unpacked _correctly_ on my linux box, and it would
be the same if I unpacked the unix .tgz file under Windows.


- windows source code (uncompressed):
source:  14308 kB (including supporting libs: 10208 kB)
windows:  4184 kB
for a total of 18556 kB


- unix source code (uncompressed):
doc:      9388 kB
scenes:   6384 kB
src:      7364 kB
for a total of 25056 kB

recompressing everything without doc and scenes (keeping include, script,
tests and ini, while at least the first two should also be distributed
seperately since they are not required for compiling the software):

povray-3.50c-src.tar.gz = 2.3 MB
povray-3.50c-src.tar.bz2 = 2.0 MB

	Just for the sources there's already more than 4 MB wasted in the
unix distribution. I do not download docs and scenes as often as I download
sources because they don't change as frequently, and those changes do not
impact the software capabilities itself.

	What should be done, IMHO:
1) Give only source code in the source file (!), and required docs such as
    povlegal and installation instructions.
2) Source code should contain supporting libraries in all platforms
3) Provide docs in as many formats as possible (HTML, XML, PDF, HLP, DOC...)
    on a seperate download.
4) Scenes, includes are not _required_ for povray to work: give them as
    seperate downloads.
5) Unify all that stuff and you've got a common source file for everybody,
    common help files (in different formats) for everybody, common scenes/include
    files for everybody.

	I don't see where's the problem here. So many projects are basically
doing so, I don't think it's only by chance or because people are lambs.

	Please note that it's _still_ only suggestions. I'm not (and won't
probably be) a POV-Team member, so I don't impose my will to the community.

	- NC

Post a reply to this message

On Thu, 13 Feb 2003 04:56:35 -0500, Christoph Hormann quoth:
> I don't really see the advantage - what would you gain by having for
> example all the mac specific files on a unix machine.  You can't use
> them.

I don't think you could even successfully uncompress some of the
Mac-specific files on a Unix system, and I *know* you can't successfully
unarchive them on a Windows system. 

-- 
Mark

Post a reply to this message

Nicolas Calimet wrote:
> 
>         What should be done, IMHO:
> [...]

Just because you do not understand the reasons for the way certain things
are handled does not mean they don't make sense.  The reaon for the unix
source package containing the docs and sample scenes is *really* trivial
for example.

If the only reason for your proposal is the reduced download volume for
those few who want the source for several platforms (and this is the only
argument that has been given in this thread so far) you should drop the
subject because that's really not enough.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 31 Dec. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

Nicolas Calimet wrote:
> 
>> As for the libraries I agree with you. They do not really belong to
>> the source code of povray. I would suggest to move them outside the
>> povray package and provide separate archives.
> 
> In principle I would agree, but in practice, for easy installations
> I would actually choose to include the supporting libraries in all
> distributions (or the unique one if everything is unified). If your system
> has better/newer libraries, you can use them. If however one or more
> library are missing, just use the one provided with the sources. In the
> unix configure file that I'm rewritting, this decision could be made
> automatically.

OK, OK, I got it. You, Thorsten and Vadim convinced me. It's easier and
more convenient to simply include the libs. They are not so large to 
justify saving some bandwidth.

Best regards
Thomas

Post a reply to this message