configure & build: Rework legacy GCC detection to parse versions outside of Jam.

Jam comparison logic is string-based, and so was detecting GCC >= 10
as being < 2. This rectifies that by removing the GCC version parsing
from Jam logic entirely, and setting various BuildConfig variables
instead.

Change-Id: I0c0ae3b9002fb5e77f9ca7a78600c91871657f03
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3293
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>

fs_shell: Prevent inclusion of BSD headers; fix DeviceOpener.

bfs_shell: build fix.

bfs: add stub for ResizeVisitor.

This allows to have all the tools (resizefs, fs_shell, etc) merged, and
split out the remaining BFS resize changes in a way that makes some
sense. We can easily merge all the basic infrastructure (ioctls, etc)
without any of the actual resizing code (I'll leave that to
professionals).

fs_shell: 'resizefs' command

Change-Id: Ie4c18c76cd1a69945739817ecd99409b7611dd7a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/939
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>

BFS: Only compile with -O1 under GCC2.

GCC7+ does not have whatever compiler bugs plague GCC2, so we can
use -O2 there as usual.

BFS: Set -std=c++11 in bfs_shell c++flags for gcc >= 3

Required for use of non-static data member

clang complains about this line in CheckVisitor.cpp:
memset(&Control().stats, 0, sizeof(check_control::stats));

some explination:
https://stackoverflow.com/questions/29359661/clang-error-invalid-use-of-non-static-data-member
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2253.html

Referencing a non-static data member inside a struct was retroactively
made undefined in C++98 and only allowed on C++11 even though gcc
permits the code to compile.

No change to functionality intended.

Thanks Jérôme and waddlesplash

Change-Id: Ic6bc332cf2796c709584488c60a067cd341bf894
Reviewed-on: https://review.haiku-os.org/c/1503
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>

build: Deprecate SetSubDirSupportedPlatformsBeOSCompatible.

By default, all targets support the "haiku" platform, and we no longer
support building for BeOS, Dan0, Zeta, or other BeOS-compatible targets,
so this is no longer needed.

Also remove all references to the non-Haiku compatible platforms, and
change all BEOS_COMPATIBLE checks to HAIKU_COMPATIBLE. Removal of
all SetSubDirSupportedPlatformsBeOSCompatible invocations
will be in the next commit.

bfs: split checkfs code into FileSystemVisitor and CheckVisitor

Another FileSystemVisitor implementation will be used for resizing

Change-Id: I2d5f47dcbefb4c76834487b194a99c6f5ae7de50
Reviewed-on: https://review.haiku-os.org/c/923
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>

libhaikucompat: Delete.

Was decoupled from the build since the switch to use libroot_build
even on Haiku.

Revert "filesystems: we aren't BeOS, so we can safely use -O2(+)."

This reverts commit ae495ca8fe9e48dea982cf522c5c54c56dffb9fd.

My system volume was mysteriously corrupted while booting or shutting down today,
enough to make it unbootable and KDL on attempt to mount it. I'm assuming our gcc2
still isn't safe with regard to -O2 optimization of filesystems, and revert this,
until proven wrong (eg. by running test suites and FS stress tests and finding no
issues.

Axel comented on the commit saying it probably was not a good idea, but no action was
taken. Should we setup a better commit review system?

filesystems: we aren't BeOS, so we can safely use -O2(+).

bfs: Use the QueryParserUtils instead of its own copy.

* Ingo copied the methods into a shared location, and then obviously
"forgot" to let BFS use them. As a side note for Ingo: the complete
error GCC reported was "std::fssh_size_t" not defined with the macro
wrapper as code location. The actual problem was a "using std::size_t"
in some C++ header that accidentally got included after the wrapper.
* The shared Query code is not yet used. That'll be done another time.
* Renamed BFS_SHELL define to FS_SHELL, such that QueryParserUtils can be
used in any file system shell, not just the bfs_shell.

Made the duplicate_array endian safe. Cleanup.

* Renamed the sorted_array to duplicate_array (which was only a typedef
before), and moved it into the BPlusTree.cpp file, as its specific to
that one.
* Utilities.cpp is no longer needed.
* Introduced endian safe getters/setters so that little endian BFS volumes
should now work fine on a big endian architecture.

Added "checkfs" as additional command for the bfs_shell.

Patch by kaliber (ticket #6333): Removed many instances of
passing an additional -Wall to the compiler, which may actually
have unwanted effects. -Wall is standard by the build system.
Also, -Wno-multichar was passed unnecessarily for Haiku targets.
I didn't remove it for the bfs_shell, hope this is what Ingo meant
in the ticket.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39314 a95241bf-73f2-0310-859d-f6bbb57e9c96

Add a private B_ATTR_CHANGE_NOTIFICATION flag to the open query syscall to tell the query to send notifications when an entry attribute changed and the entry stays in the query. Previously you only get created and removed messages, now you can also get updated messages. Only implement it for bfs.
Fix copy right.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39131 a95241bf-73f2-0310-859d-f6bbb57e9c96

Don't include HaikuBuildCompatibility.h in the [b]fs_shell build. It's not
needed -- the code has its own complete platform abstraction layer -- and
only causes problems.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34270 a95241bf-73f2-0310-859d-f6bbb57e9c96

Define __STDC_FORMAT_MACROS directly in HOST_DEFINES.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34217 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Introduced new header directory "config", which ATM contains HaikuConfig.h
and types.h. The idea is to provide a basic architecture/compiler
abstraction by defining types and macros that allow the posix/ and os/
headers to be mostly architecture/compiler agnostic.
* Adjusted the posix/ and os/ headers accordingly.
* <SupportDefs.h>: Introduced B_PRI* and B_SCN* macros similar to the PRI*
and SCN* macros defined in <inttypes.h>, just for the BeOS/Haiku [u]int*
types and some POSIX types (e.g. off_t, dev_t, ino_t) that don't have POSIX
macros. Also the B_PRI* and B_SCN* macros are available unconditionally,
unlike the <inttypes.h> macros, which require __STDC_FORMAT_MACROS to be
defined in C++ mode.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34214 a95241bf-73f2-0310-859d-f6bbb57e9c96

Moving the bfs_fuse build into another directory would probably be the way to
go, but for the time being at least don't cause the BFS sources to be compiled
twice regardless of which target is built.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34204 a95241bf-73f2-0310-859d-f6bbb57e9c96

Link bfs_fuse against the static host libroot.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31487 a95241bf-73f2-0310-859d-f6bbb57e9c96

Patch by Raghuram Nagireddy:
Re-use the kernel emulation of the FS shell to implement a FUSE module
for BFS. In theory, it could use any Haiku file system implementation
just like the FS shell itself, but currently only the BFS code supports
being compiled as an FS shell module. The build target is <build>bfs_fuse
On Ubuntu, you would do this:

sudo apt-get install libfuse-dev
jam \<build\>bfs_fuse
mkdir path/to/moundPoint
path/to/bfs_fuse /dev/sdaX path/to/mountPoint

And that will mount your BFS volume at /dev/sdaX
read/write. As this is new code, you should be careful with your
data and expect potential data loss. Not that I don't trust Raghu's
code, but a warning is always better with such things. So far, my
tests have been successful and it is great to finally have write
support for BFS in Linux! Thanks a lot, Raghu, for your great work!


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31409 a95241bf-73f2-0310-859d-f6bbb57e9c96

Patch by Andreas Faerber with changes by myself: Work towards Solaris
build platform support.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26899 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Moved helper function to check initialization parameters to separate
source file. Added function to check the volume name.
* Removed bfs_validate_initialize(). This functionality is to be implemented
in a userland add-on.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22871 a95241bf-73f2-0310-859d-f6bbb57e9c96

Added Haiku as host platform supported by the build system ("haiku_host").
Completely untested yet.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21802 a95241bf-73f2-0310-859d-f6bbb57e9c96

Missed this one.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20970 a95241bf-73f2-0310-859d-f6bbb57e9c96

Changed grist.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20969 a95241bf-73f2-0310-859d-f6bbb57e9c96

Link against libhaikucompat_build.a and the STL library.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20937 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Prepared the BFS sources to be used with the new FS shell:
- Moved all inclusions of system headers into a new
system_dependencies.h header, which conditionally either includes
these or the FS shell headers.
- Fixed compiler warnings related to printf-like functions (int32 is
int, not long on non-BeOS platforms).
* Build a new bfs_shell. Compiles and links, but does nothing ATM.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20860 a95241bf-73f2-0310-859d-f6bbb57e9c96

Revert "filesystems: we aren't BeOS, so we can safely use -O2(+)."

This reverts commit ae495ca8fe9e48dea982cf522c5c54c56dffb9fd.

My system volume was mysteriously corrupted while booting or shutting down today,
enough to make it unbootable and KDL on attempt to mount it. I'm assuming our gcc2
still isn't safe with regard to -O2 optimization of filesystems, and revert this,
until proven wrong (eg. by running test suites and FS stress tests and finding no
issues.

Axel comented on the commit saying it probably was not a good idea, but no action was
taken. Should we setup a better commit review system?

filesystems: we aren't BeOS, so we can safely use -O2(+).

bfs: Use the QueryParserUtils instead of its own copy.

* Ingo copied the methods into a shared location, and then obviously
"forgot" to let BFS use them. As a side note for Ingo: the complete
error GCC reported was "std::fssh_size_t" not defined with the macro
wrapper as code location. The actual problem was a "using std::size_t"
in some C++ header that accidentally got included after the wrapper.
* The shared Query code is not yet used. That'll be done another time.
* Renamed BFS_SHELL define to FS_SHELL, such that QueryParserUtils can be
used in any file system shell, not just the bfs_shell.

Made the duplicate_array endian safe. Cleanup.

* Renamed the sorted_array to duplicate_array (which was only a typedef
before), and moved it into the BPlusTree.cpp file, as its specific to
that one.
* Utilities.cpp is no longer needed.
* Introduced endian safe getters/setters so that little endian BFS volumes
should now work fine on a big endian architecture.

Added "checkfs" as additional command for the bfs_shell.

Patch by kaliber (ticket #6333): Removed many instances of
passing an additional -Wall to the compiler, which may actually
have unwanted effects. -Wall is standard by the build system.
Also, -Wno-multichar was passed unnecessarily for Haiku targets.
I didn't remove it for the bfs_shell, hope this is what Ingo meant
in the ticket.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39314 a95241bf-73f2-0310-859d-f6bbb57e9c96

Add a private B_ATTR_CHANGE_NOTIFICATION flag to the open query syscall to tell the query to send notifications when an entry attribute changed and the entry stays in the query. Previously you only get created and removed messages, now you can also get updated messages. Only implement it for bfs.
Fix copy right.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39131 a95241bf-73f2-0310-859d-f6bbb57e9c96

Don't include HaikuBuildCompatibility.h in the [b]fs_shell build. It's not
needed -- the code has its own complete platform abstraction layer -- and
only causes problems.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34270 a95241bf-73f2-0310-859d-f6bbb57e9c96

Define __STDC_FORMAT_MACROS directly in HOST_DEFINES.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34217 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Introduced new header directory "config", which ATM contains HaikuConfig.h
and types.h. The idea is to provide a basic architecture/compiler
abstraction by defining types and macros that allow the posix/ and os/
headers to be mostly architecture/compiler agnostic.
* Adjusted the posix/ and os/ headers accordingly.
* <SupportDefs.h>: Introduced B_PRI* and B_SCN* macros similar to the PRI*
and SCN* macros defined in <inttypes.h>, just for the BeOS/Haiku [u]int*
types and some POSIX types (e.g. off_t, dev_t, ino_t) that don't have POSIX
macros. Also the B_PRI* and B_SCN* macros are available unconditionally,
unlike the <inttypes.h> macros, which require __STDC_FORMAT_MACROS to be
defined in C++ mode.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34214 a95241bf-73f2-0310-859d-f6bbb57e9c96

Moving the bfs_fuse build into another directory would probably be the way to
go, but for the time being at least don't cause the BFS sources to be compiled
twice regardless of which target is built.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34204 a95241bf-73f2-0310-859d-f6bbb57e9c96

Link bfs_fuse against the static host libroot.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31487 a95241bf-73f2-0310-859d-f6bbb57e9c96

Patch by Raghuram Nagireddy:
Re-use the kernel emulation of the FS shell to implement a FUSE module
for BFS. In theory, it could use any Haiku file system implementation
just like the FS shell itself, but currently only the BFS code supports
being compiled as an FS shell module. The build target is <build>bfs_fuse
On Ubuntu, you would do this:

sudo apt-get install libfuse-dev
jam \<build\>bfs_fuse
mkdir path/to/moundPoint
path/to/bfs_fuse /dev/sdaX path/to/mountPoint

And that will mount your BFS volume at /dev/sdaX
read/write. As this is new code, you should be careful with your
data and expect potential data loss. Not that I don't trust Raghu's
code, but a warning is always better with such things. So far, my
tests have been successful and it is great to finally have write
support for BFS in Linux! Thanks a lot, Raghu, for your great work!


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31409 a95241bf-73f2-0310-859d-f6bbb57e9c96

Patch by Andreas Faerber with changes by myself: Work towards Solaris
build platform support.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26899 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Moved helper function to check initialization parameters to separate
source file. Added function to check the volume name.
* Removed bfs_validate_initialize(). This functionality is to be implemented
in a userland add-on.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22871 a95241bf-73f2-0310-859d-f6bbb57e9c96

Added Haiku as host platform supported by the build system ("haiku_host").
Completely untested yet.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21802 a95241bf-73f2-0310-859d-f6bbb57e9c96

Missed this one.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20970 a95241bf-73f2-0310-859d-f6bbb57e9c96

Changed grist.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20969 a95241bf-73f2-0310-859d-f6bbb57e9c96

Link against libhaikucompat_build.a and the STL library.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20937 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Prepared the BFS sources to be used with the new FS shell:
- Moved all inclusions of system headers into a new
system_dependencies.h header, which conditionally either includes
these or the FS shell headers.
- Fixed compiler warnings related to printf-like functions (int32 is
int, not long on non-BeOS platforms).
* Build a new bfs_shell. Compiles and links, but does nothing ATM.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20860 a95241bf-73f2-0310-859d-f6bbb57e9c96