Rename and move gcc4 builds on haiku-file

[pulkomandy]

​http://www.freelists.org/post/haiku-development/Enforcing-gcc2h-was-Alpha-3-better-late-than-never

According to this discussion, there is some confusion because haiku-files doesn't make it clear enough that gcc2hybrid is the only way.

Make the following changes :

• Keep the gcc2hybrid as is on the main page
• Rename the plain gcc2, plain gcc4, and gcc4hybrid images as 'walter' instead of 'haiku'. These are already de-branded inside (splash screen and desktop background).
• Move the gcc4 and gcc4hybrid to a separate page,something like ​http://haiku-files.org/gcc4/anyboot/ (or whatever makes sense on the server)
• Adapt the text on the main page in nightly images paragraph :

These are regularly built images always using the latest code. While we do try to keep our code in a working state at all times, these are not considered to be stable and may be broken in various ways at any given point in time. They are strictly meant for testing only. Applications made for Haiku should be carefully tested on the latest available stable release.

Official releases leading up to and including R1 Final are distributed only as a GCC 2 Hybrid for the x86 architecture. Other combinations (GCC 2 Only, GCC 4 Only, GCC 4 Hybrid) are available below, for development and testing purposes only. It is recommended to use a GCC 2 Hybrid.

• Add a section linking to the gcc4/4h/2 stuff below with such wording :

These images are for testing purposes only. They are not compatible with Haiku and shouldn't be used for software development. Unless you are testing for a compiler-dependant bug, please consider downloading a gcc2-hybrid image instead. gcc2-hybrid installations allow to run gcc4-compiled software as well, and they are more tested than these. There is no drawback for using them.

Feel free to improve the texts, but you get the idea.

[mmadia]

R1 Alpha 3 has not yet been released. This was with an R1 Alpha 3 Release Candidate image.

[deejam]

Why is this ticket in milestone R1/alpha3?

[mmadia]

One concern, for the .vmdk images the original name of the file somehow gets embedded into the image. Simply renaming the file, after a build cycle will not work.

So, should the filenames of the uncompressed images remain as-is and simply have the compressed archives renamed to use 'walter', instead of 'haiku'?

Or should the build system be adjusted to automatically switch between haiku.vmdk, haiku.image and walter.vmdk, walter.image ?

[mmadia]

I'm thinking of re-organizing the directory layout of haiku-files.org to be :

• haiku/
  • development/ (only the current release style, which is gcc2hybrid)
  • releases/ (for holding torrents)
• unsupported-builds/
  • arm/
  • m68k/
  • mipsel/
  • ppc/
  • x86-non-standard/
    • gcc2/
    • gcc4/
    • gcc4hybrid/

That directory layout will reinforce the concept that only one variant of the nightly builds are considered "supported" or "compatible" with official releases.

Since noone responded about my .vmdk filename concern, for now the uncompressed filenames will remain the same and only the archive name will be changed to "walter" or maybe even "walter_unsupported"

[luroh]

I really like the proposed layout but for simplicity's sake I'd throw in the actual images under /releases instead of just the torrents.

Since noone responded about my .vmdk filename concern, for now the uncompressed filenames will remain the same and only the archive name will be changed to "walter" or maybe even "walter_unsupported"

FWIW, as a heavy VMware user, it sounds good to me. No need to add any additional complexity to Haiku's build system.

[bonefish]

The directory structure looks OK, though I'd omit the "x86-non-standard" level and use "x86-gcc2", "x86-gcc4", "x86-gcc4hybrid" as directory names.

Regarding the naming of the unofficial images, I find "walter" a bit silly. Originally it was a joke for the OS name, later the expected code name for the first release (i.e. R1), and now its use has become somewhat inflationary. I'd simply call the unsupported images "haiku_unsupported".

[mmadia]

Sounds good. Since x86 was being broken up into individual targets, I took the time (and help from stpere) to display all image types of that target in a single table --- sort of like the get-haiku page. For anyone curious, here's the work-in-progress : ​http://www.haiku-files.org/notyet-index.html The RSS feeds are not working yet. The non-x86 pages are barely started. Hopefully, it'll be in a workable state by tomorrows end, which will allow BOM to be updated & restart uploading nightly images.

[mmadia]

(In #7807) Yep, this is due to how the images are currently being built.

Basically, BOM builds x86-gcc2, x86-gcc4, and then the hybrids. To save time, the hybrids are built within the same generated directories. x86-gcc2, x86-gcc4, and x86-gcc4hybrid's targets are jam'd with -sHAIKU_DISTRO_COMPATIBILITY=default and x86-gcc2hybrid is jam'd with -sHAIKU_DISTRO_COMPATIBILITY=official , as part of #7616.

However, it seems that jam does not realize that the change in HAIKU_DISTRO_COMPATIBILITY will alter the binary objects.

[Disreali]

Since #7807 has been fixed, would that also mean this ticket can be concidered fixed?

[mmadia]

Replying to Disreali:

Since #7807 has been fixed, would that also mean this ticket can be concidered fixed?

Sure.