adapt our build system to distro guidelines

[wkornewald]

Since others may not use our logo and trademarks we need to extend the build system. The preferred solution is probably to have good defaults (i.e.: neutral names and logos) and require us and "Haiku Compatible" 3rd-party distro makers to set a few build options. By default, no Haiku logo and trademarks would be enabled (remove from AboutHaiku and boot screen, etc.). AboutHaiku is renamed to AboutSystem and the Deskbar menu item is labeled "About This System...".

The build system would have the following options:

• default (no logos/trademarks)
• HaikuCompatible (enables a "Haiku Compatible" logo in boot screen and AboutSystem)
• Haiku (official build; enable Haiku logos and trademarks in boot logos and AboutHaiku)

I'm not sure if we should rename "About This System..." to "About Haiku..." in the official "Haiku" build.

[bonefish]

I introduced general support for discriminating the different kinds of Haiku distros in the build system (configure option "--distro-compatibility", hrev21177). I renamed AboutHaiku (hrev21179, hrev21180) and, mostly for reference, conditionally renamed the Deskbar menu item (hrev21178).

The remaining tasks are mainly about setting the alternative logos/images when those are available.

[wkornewald]

We'll also need a possibility to easily include the disclaimer in AboutSystem (also for unstable releases).

[bonefish]

Not sure what you're referring to with respect to adding the disclaimer. Is there anything that prevents it from just being added, now?

Regarding unstable releases, I wouldn't really consider an indicator of the code stability a property to be set through the build system. I suppose we might want to have a macro in <BeBuild.h> indicating the state of the sources. Maybe something like:

#define B_RELEASE_STABILITY_DEVELOPMENT	0
#define B_RELEASE_STABILITY_PRE_ALPHA	1
#define B_RELEASE_STABILITY_ALPHA	2
#define B_RELEASE_STABILITY_BETA	3
#define B_RELEASE_STABILITY_GAMMA	4
#define B_RELEASE_STABILITY_STABLE	5

#define B_HAIKU_VERSION			...
#define B_HAIKU_RELEASE_STABILITY	B_RELEASE_STABILITY_DEVELOPMENT

Opinions?

[wkornewald]

Replying to bonefish:

Not sure what you're referring to with respect to adding the disclaimer. Is there anything that prevents it from just being added, now?

No, it just requires fiddling with the source. Maybe we could move the disclaimer template text into AboutSystem (as a separate file) and automatically include it when building a compatible distro? When building a "compatible" distro it would be even better if the configure script required specifying the distro name and contact information and optionally a distributor name and then automatically set that info in the disclaimer. Or does this make it too easy to create a compliant 3rd-party distro? :)

Regarding unstable releases, I wouldn't really consider an indicator of the code stability a property to be set through the build system. I suppose we might want to have a macro in <BeBuild.h> indicating the state of the sources. Maybe something like:

Shouldn't the release stability be part of a private header? IMHO, it's not really necessary for 3rd-party apps and changes shouldn't trigger a complete rebuild of Haiku.

[wkornewald]

Something else coming to my mind: when building a "compatible" distro the build system should check whether you're using a compatible GCC version (e.g., 2.95.3 on x86).

[mmadia]

Should this be added to the R1/Alpha blockers?

[mmadia]

With the recent ​From OpenBeOS to Haiku thread on the [haiku] mailing list, could Walter become the name for un-official builds of Haiku?

[bonefish]

The build system part has been implemented. The applications (e.g. AboutSystem), the boot loader, and anything else that contains Haiku trademarks needs to be adjusted.

[mmadia]

There's a few reasons for closing this ticket:

• As Ingo stated above, the implementation as far as the build system supporting it has been implemented.
• With recent discussions revolving around distributions(eg Basho) & trademarks, it has been expressed to place a stronger focus on protecting Haiku's trademarks and placing the burden to remove trademarks on the 3rd Party.
• If for some reason, it is desired to make removal of trademarks, then individual tickets should be opened for each component. eg, AboutSystem, Installer, bootloader, or any future components that may utilize Haiku's trademarks.