cmake shouldn't define UNIx variable

[pulkomandy]

It is well known that Haiku isn't unix.

 http://www.vtk.org/Wiki/CMake_Useful_Variables#System_.26_Compiler_Information
This page tells that UNIX variable is set on 'Unix-like' systems. It is, for example, set on Mac OS X and cygwin, but not MSYS, which is as unixish as Haiku, with a bash shell and most of the GNU tools.

When UNIX is set, apps built using cmake are expecting an X11 server, and FHS file hierarchy ( http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard), both of them are not available in Haiku.

So, cmake shouldn't set the UNIX variable, and apps should rely on the HAIKU variable to get their configuration. This way, installing files in the right path at compile time (/boot/common/ instead of /usr/local) would become much easier.

[augiedoggie]

Replying to pulkomandy:

It is well known that Haiku isn't unix.

It's probably closer to UNIX than any other OS model.

 http://www.vtk.org/Wiki/CMake_Useful_Variables#System_.26_Compiler_Information
This page tells that UNIX variable is set on 'Unix-like' systems. It is, for example, set on Mac OS X and cygwin, but not MSYS, which is as unixish as Haiku, with a bash shell and most of the GNU tools.

When UNIX is set, apps built using cmake are expecting an X11 server, and FHS file hierarchy ( http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard), both of them are not available in Haiku.

Then that's a flaw in the project you're trying to build. X11 isn't guaranteed on OSX or any other UNIX, and the various UNIX/Linux distros violate the FHS at will.

So, cmake shouldn't set the UNIX variable, and apps should rely on the HAIKU variable to get their configuration. This way, installing files in the right path at compile time (/boot/common/ instead of /usr/local) would become much easier.

The prefix should already default to /boot/common. If it isn't, then there is a regression or the project you're trying to build is overriding the default.

I had requested a HAIKU variable in the past from them and they haven't responded. I don't have a problem with defining it in addition to the BEOS variable but I wouldn't think it's critical.

[michaelvoliveira]

Please take a look at #399
http://ports.haiku-files.org/ticket/399

[pulkomandy]

Haiku is POSIX. That doesn't make it completely UNIX.

MSys halso has a POSIX layer, even if it runs under Windows.

Both of them have no X11, no FHS (Haiku is even 'worse' than MSYS on this), and both don't use a kernel that comes from the UNIX world. Both of them are POSIXand use bash as the main shell. Both of them use gcc as a compiler, gnu make, and most other gnu tools.

OSX, on the other hand, is really based on an UNIX forked kernel. So it has the UNIX features, not as a compatibility layer like MSys or Haiku, but right in the kernel, as the native programming API. It has no X11 either, but right, it's still UNIX.

Anyway, the choices under these variables in cmake seems rater fuzzy to me. But UNIX is more than POSIX API, so it makes more sense to not define it on Haiku.

Of course, this means more work for porters (you have to check where Haiku is actually like UNIX and where it is not), but it ensures that well, you checked it.

If we try to compile an ap or lib that had a BeOS port, in the current situation both BeOS and UNIXwould be set by cmake, and the app build system could be confused by that. Since there is a BeOS variable, why not just use that, even if it is only a distant legacy for us (like UNIX is for OSX), instead of mixing it up with something that is only remotely matching our way.

If UNIX doesn't give you insurance that there is FHS, no X11, then what's left ? POSIX ? BeOS already tells most of it is here. Sure, Haiku is more POSIX than BeOS, but that doesn't make it UNIX. It's just a different flavour of BeOS.

[augiedoggie]

Replying to pulkomandy:

Haiku is POSIX. That doesn't make it completely UNIX.

MSys halso has a POSIX layer, even if it runs under Windows.

You're talking about one api stacked on top of the native one. To me it makes sense to not define the variable automatically for this type of setup.

Both of them have no X11, no FHS (Haiku is even 'worse' than MSYS on this), and both don't use a kernel that comes from the UNIX world. Both of them are POSIXand use bash as the main shell. Both of them use gcc as a compiler, gnu make, and most other gnu tools.

Haiku has the abililty to run an X server. If I'm not mistaken kaliber even has one in his tiltos repository.

OSX, on the other hand, is really based on an UNIX forked kernel. So it has the UNIX features, not as a compatibility layer like MSys or Haiku, but right in the kernel, as the native programming API. It has no X11 either, but right, it's still UNIX.

I don't consider the posix api to be a compatibility layer for Haiku. The "native" c++ api can't do everything the posix stuff can do. I'm pretty sure large portions of the "native" api is built using posix calls. So which one is really the base api?

Anyway, the choices under these variables in cmake seems rater fuzzy to me. But UNIX is more than POSIX API, so it makes more sense to not define it on Haiku.

At what point does it become UNIX? We have the same compiler toolchain, the same api(including things like pthreads/domain sockets/etc....), similar set of userland tools, the same basic filesystem layout(directories that end with leaves like /bin or /etc), users are managed through a "passwd" file, and so on, and so on, and so on.....

Of course, this means more work for porters (you have to check where Haiku is actually like UNIX and where it is not), but it ensures that well, you checked it.

Isn't the point to make the porting work easier by setting defaults that will probably work?

If we try to compile an ap or lib that had a BeOS port, in the current situation both BeOS and UNIXwould be set by cmake, and the app build system could be confused by that. Since there is a BeOS variable, why not just use that, even if it is only a distant legacy for us (like UNIX is for OSX), instead of mixing it up with something that is only remotely matching our way.

I doubt there are very many BeOS apps that were built with cmake. Even so, there are a thousand ways the build systems could be confused. It takes about 2 seconds to add a "NOT BEOS" clause in the build scripts if it's needed. You can even do a string match on the SYSTEM_NAME variables if you really want to know if it's Haiku.

If UNIX doesn't give you insurance that there is FHS, no X11, then what's left ? POSIX ? BeOS already tells most of it is here. Sure, Haiku is more POSIX than BeOS, but that doesn't make it UNIX. It's just a different flavour of BeOS.

As stated above...
It's the posix api(including pthreads/sockets/etc...), the compiler toolchain(gcc, binutils, make, etc...), basic command line tools(sed, awk, sh, etc....), basically "similar" directory structure, path separators, environment variables, ..........

I think you are trying to fit your definition of unix with the one that cmake uses. The cmake version is not so strict and makes a for a good starting point on any port.

[tqh]

If nothing else setting the UNIX flag will confuse a lot of people that we are UNIX, hide subtle bugs where UNIX and Haiku differs and hide details which the porter should take care of.

It will also mix a lot #ifdef UNIX.. #ifdef Haiku, make Haiku dependent on the UNIX code (which will be much harder to maintain due to different UNIX systems have to agree on changes. All of them subtly different..)

As one of the old Firefox porters I'd drop that UNIX flag as fast as I could.

[bonefish]

Replying to tqh:

If nothing else setting the UNIX flag will confuse a lot of people that we are UNIX,

Who cares?

hide subtle bugs where UNIX and Haiku differs and hide details which the porter should take care of.

Where Haiku implements POSIX functionality, the behavior should not differ from that of other platforms. Moreover most projects have test suites that uncover issues (often in Haiku rather than the port, BTW).

It will also mix a lot #ifdef UNIX.. #ifdef Haiku,

If done by a competent porter this will not happen. The Haiku specifics should be kept to a mere minimum anyway.

make Haiku dependent on the UNIX code (which will be much harder to maintain due to different UNIX systems have to agree on changes. All of them subtly different..)

On the contrary! Using the portable (POSIX) implementation reduces the work for the initial port -- because one doesn't have to do Haiku specific implementations -- and also for maintaining the port -- because others maintain the portable code.

As one of the old Firefox porters I'd drop that UNIX flag as fast as I could.

Unlike Firefox cmake is not GUI-heavy. Command line applications often need POSIX functionality only and there are enough examples where declaring Haiku UNIXish has reduced the porting work (e.g. Perl or APR). Anyway, as Chris explained, whether or not this makes sense for cmake as well solely depends on what specifying this flag implies in the cmake context. If it's already a close approximation for Haiku, that's the way to go.

[pulkomandy]

the problem is not cmake itself. "UNIX" here is a variable that is set for all applications/projects built using cmake. This may include GUI apps as well.
Wether the code is shared between Haiku and UNIX is a choice of the developper, on a case by case basis. It's not up to the build system to decide if an app should do the unix way in haiku.

It's like if our gcc would define linux for easier porting. Sure, this avoids many #if defined(linux)

defined(haiku) in the code, but in the cases when you actually need haiku-specific code, you can't do :

#ifdef linux
#elsif defined(haiku)
#endif

I'd expect that to work.

Sure, UNIX is broader than linux. But the result is the same : when developping on Haiku, I don't expect UNIX to be defined, even if there are a lot of similarities.

[bonefish]

Replying to pulkomandy:

the problem is not cmake itself. "UNIX" here is a variable that is set for all applications/projects built using cmake. This may include GUI apps as well.

Graphics are not part of UNIX.

Wether the code is shared between Haiku and UNIX is a choice of the developper, on a case by case basis. It's not up to the build system to decide if an app should do the unix way in haiku.

I really don't get your point. The difference the UNIX flag does make is: Possibly having out of the box support -- as long as as only POSIX features Haiku supports are needed -- vs. having no support for sure. Why is the latter better?

It's like if our gcc would define linux for easier porting. Sure, this avoids many #if defined(linux)

defined(haiku) in the code, but in the cases when you actually need haiku-specific code, you can't do :

#ifdef linux
#elsif defined(haiku)
#endif

I'd expect that to work.

Sure, UNIX is broader than linux.

UNIX means a family of operating systems, Linux a single operating system, so this comparison is utterly flawed. Ironically Linux isn't even officially UNIX (i.e. registered as SUS compliant).

But the result is the same : when developping on Haiku, I don't expect UNIX to be defined, even if there are a lot of similarities.

Generally UNIX means POSIX compliant and that's what Haiku is (mostly) striving for. Since cmake's UNIX flag is binary, defining it is likely closer to the truth than not defining it. Assuming that it actually stands for UNIX/POSIX.