In article <3E4### [at] freefr> , Nicolas Calimet <pov### [at] freefr>
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.

    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

Nicolas Calimet wrote:
> 
> > Do you suggest there should be an official complete source package with
> > the platform specific files of all platforms?
> 
>         Yes, this is exactly what I meant. Unified source. No redundancy.
> Archive provided in different formats (zip, rar, tar.gz, tar.bz2, ...)
> instead of platform-specific. Same filename for all as a big advantage  :o)

No.  As Thorsten explained this would not work because the file formats
are not platform independent.  The whole thing would result in one archive
for each platform again, the only difference would be that it would
contain a lot of files not needed for the user.

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.

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

On Thu, 13 Feb 2003 11:26:40 +0100, 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.

The MegaPOV core was taken from windows core code and is succesfully compiled
with all supported platforms, so does POV really not work the way you want ?

I'm already tried compilation of Sources with many compilers in a few
platforms and I can group changes as follow:
- playing with compiler/linker settings
- playing with warnings
- playing with bugs and limitations in compiler
- playing with settings from config.h
- adding additional header files

Usually none of those changes can be predicted by programing with different
compiler on different platform so changes usually still require platform
specific fiddling. But it is not difficult work when such project like
http://megapov.inetart.net/manual/internals.html is started. For the next
MegaPOV this chapter will be probably updated with some more info about
Digital Mars C++ (imo fastest compilation and easiest installation I meet with
community and development somehow similiar to POV), recently released final
OpenWatcom 1.0 (I really interested how it will work) and (if I will be able
to setup MacOS 8.6 and MPW) MrCpp compiler. Please note this work is rather
more general and it can be applied to any patched releases and is mostly not
connected with source core code shape itself.

ABX

Post a reply to this message

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