When HEAD is tagged, the output will be identical to what it was
before (the latest hrev tag and nothing else.) When HEAD is not tagged,
and the most recent tag is further back, we now use a format like this:
hrevXXXXX+N(+dirty)
... where N is the number of commits since hrevXXXXX, and +dirty is added
if the working tree is dirty. This is significantly shorter than the
previous model (as it does not have the Git revision.)
Fixes#14445.
Change-Id: Ide7f66cf0ac1c1f05402afc52b6be3b68b66d6dc
Reviewed-on: https://review.haiku-os.org/566
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* PRE_BETA_2 is now the default in master.
* For libbe: R1/alpha4 used internal=8, but nobody bumped master
at the same time, so now we are on internal=9.
It is just straight up broken on most systems without this, as
the same "cast specifies signature type" appears there too.
Exactly why this fixes the problem does not appear to be any more known
than it was when this was first instated in 2012.
The latter is not just a symlink to the former, but is a small pseudo-
library that tells the linker to use the .so.1 version instead. As we
do not pass -L to this directory to the linker invocation, the linker
thus cannot find it, and so errors out.
We rightly do not want the linker doing "magic" things for us that
we don't expect, and so even if this one case is fine, we shouldn't
allow the linker to take care of this automatically for us when
it comes to libroot and other core system functionality, especially
as going forward we may indeed add a second libgcc version due to ABI
breaks. Instead, link against .so.1 directly.
Fixes the build breakage caused by the GCC 7 bump.
We now build libicns against it. It seems that it is better-maintained than
JasPer, so we should probably consider switching the JPEG2000Translator to
use it also.
ffmpeg_devel pulls in some other devel packages we don't really need,
and very few things are built against it anyway, so whoever needs it
can install it manually. Same goes for freetype and fontconfig.
* Store pointers in an addr_t instead of int32, for 64-bit's sake
* Use DebugSupport.h instead of userlandfs Debug.h and remove extra parentheses
* Create a header-only String class based on the userlandfs String and use it
* RecursiveLock instead of Locker.
* Jamfile cleanups and other misc. changes.
It isn't yet adapted to the new VFS API, so the build is still somewhat
broken.
This contains the contents of Haiku's sources, which is necessary
to include in "with source" builds for proper (L)GPL compliance,
mostly because we have GPL code in the tree.
"cpp" is the system C preprocessor, not the one from our cross-compiler,
and in the case of my system which does not have GCC installed at all,
it doesn't even exist.
With this, Clang-ARM builds successfully create a "haiku-arm.mmc".
I couldn't get it to output, even after blessing it with "rune",
but that may just be my fault...
Now that HOST_CC is actually passed in, we need to default
everything to it; otherwise, it's up to the Jambase as to
what CC we are actually using.
Found by trying to build Haiku on a system that has no "cc"
executable, but Jam tried to use it anyway (as all three of CC,
C++, and LINK.)
The former is passed to the compiler when linking using it,
the latter is passed to ld when it is invoked directly.
Also modify ArchitectureRules to not overwrite this setting.
This rule process the entire target's source files at once, and so
whoever wrote this rule in the first place (PulkoMandy?) probably
assumed without even testing that "cc -E" would create multiple
outputs for multiple inputs.
It doesn't, though: it just outputs them in sequence on the command line
the same way it does when the files are piped in through "cat". This
also has other advantages (e.g. preprocess errors caused by the compiler
assuming it was C not C++ code and so not defining __cplusplus, local
includes are now resolved properly, etc.)
Doing it this way does exposes other problems like the one fixed in the
previous commit (headers with no context defined, which worked previously
only because they used the context of the preceding `cat`'ed file.)
We now also remove the .pre file after collecting the catkeys.
Otherwise, Clang warns that we haven't set an architecture on ARM,
which is set in CCFLAGS. Since these might also contain other flags
that affect the preprocessor, there isn't any good reason to not
pass it through, so do that.
It seems that at on some platforms at least, Clang uses @define instead
of #define, but with functionally identical syntax, so use sed to
process it as such.
We lost these tunings when I moved us away from board focused
builds. I feel like most of our ARM interest is around ARMv7+
Change-Id: Ie301d275a74d48ee3d0c4c7dc7d6cdd635288a7b
This requires a trunk build of Clang (the flag was only implemented
& introduced 12 days ago), but at present, full builds will fail
due to an unrelated Clang bug: https://bugs.llvm.org/show_bug.cgi?id=38356
* __NO_INLINE__ fixes the cross-build on some glibc-based systems with
newer compilers, as it prevents glibc from declaring functions inline
that we override in libroot_build.
* We can now enable tree-vrp as long as no-delete-null-pointer-checks
goes where it used to.
The lowest model number supported by this driver is "3160", but that's just
Intel's insanity: the 7260 was released the quarter before it. So following
our naming convention strictly, "7260" is the correct name for this driver.
The firmware situation for this one is also a little different. Unlike past
instances where Intel has released mostly nonsubstantial firmware updates,
allowing us to just copy a recent-ish version from the iwlwifi archives,
the firmware is more closely tied to the driver in this series. As a result,
some of this firmware is not even used by Linux yet (they're a few versions
behind it seems), so the firmware packages included here come from FreeBSD.
One major hardware feature - RX of multiple frames at a time - is disabled
in this commit, as it depends on mbuf reference-counting, according to the
FreeBSD developers I asked, which we do not implement yet. I'll hopefully
get to looking at that in the next few weeks.
And with that, I finally have WiFi on my primary laptop, my original reason
for setting out on this quest last year. This commit was pushed through it,
even :)
This was accomplished by adding some pretty nasty hacks to the FFmpeg recipe
so that we can compile it for the GCC2 ABI using GCC7. This works because
GCC's C ABI has not changed between GCC2 and GCC7.
As a consequence of this, pretty much all the longstanding issues of the
ancient-and-still-miscompiled FFmpeg 0.10 are now completely gone.
Fixes#5080, #8461, #12696, #12436, #13981#13410, #13337.
Closes (possibly fixed earlier) #8605, #8511, #6984.
Probably fixes (couldn't test) #13989, #11974.
* Remove WifiFirmwareScriptData; the new mechanism is to use the script
to create a true package, and it also supports the offline downloading
this would have provided.
* Remove "FFMpeg"; never used -- the "ffmpeg" package is actually added
via BuildFeatures.
* Remove Bluetooth; now provided as part of the main Haiku package.
Also add AddHaikuImageSourcePackages invocations for all relevant
(i.e. [L]GPL'ed) packages.
Doesn't truly fix#9990 as PackageKit cannot be used to install source
packages, but this is enough for creating a redistributable image,
so that ticket can be moved out of the beta1 milestone now.
No functional change. Ideally we would create these via ResAttr like we do
the mail-providers, but these have attributes on their directories and not
just the files, so that will be slightly trickier, so for now just keep them
in their zip format.
* The if-case was appending to gccBaseFlags after the rest of the file
was done using it, so it was ineffective. Now we set it with the rest
of the baseFlags.
* We already pass no-integrated-as in configure, no need to do it in
MainBuildRules.
* B_USE_BUILTIN_ATOMIC_FUNCTIONS isn't used anymore, so get rid of it.
Most of the problems with tree-vrp stemmed from its deletion of null-pointer
checks (see linked commit in the source.) Now, GCC has a flag to control that,
and with it enabled I can boot to the desktop even with tree-vrp enabled.
On GCC 7.3, it conflicts with our definition of 'fork'. The documentation
states that disabling builtins has no effect on versions where they
do not exist, so we don't need to check for GCC7 here.
Previously they just silently continued, which meant that if part of the
cross-tools build failed, you would have to scroll back pretty far to
see what the failure was.
* The ram_disk driver was missing in the bootstrap images. Adding
it will allow the ramdisk command to work. And with a modified
haikuports.conf one might even use a ramdisk TREE_PATH.
* The virtio_net driver will probably be handy in some situations.
git_svn needs alien_svn, but we don't include this in the build repos.
Remove it from the preinstalled software, it is available in the depot
if people need it.
John's revert of my removal commit dragged back a bunch of cygwin/sunos
cruft, as well as re-adding RegExp.cpp to the host libshared, that we don't
need.
Instead, remove this and add libgnuregex_build to just the tools/keymap
link alongside the FreeBSD gnuregex case.
Following recent changes to use libroot_build on Haiku also, it is now
actually impossible to build Haiku components on non-Haiku platforms
(BeOS R5, Dan0, BONE, Zeta), so we can remove any logic related to this.
This is only the first part; still to be removed are:
* SetSubDirSupportedPlatformsBeOSCompatible
* HOST_PLATFORM_BEOS_COMPATIBLE
* TARGET_PLATFORM_BEOS_COMPATIBLE
To quote jscipione (from 95e8362c52),
"Let me tell you a story about a bug" -- though this tale spans a much
lesser time than that one did.
In 5e19679ea3, I enabled libroot_build for
Haiku, instead of using the system libroot as we had before. There were
a number of bugs introduced along with this that I hadn't fixed (and there
may be more after this), but most of the obvious ones (crashes on x86_64...)
were fixed shortly enough.
Attribute usage, though, was a different story. Unlike most of the POSIX
calls in libroot, which were aliasing system functions no matter what the
platform, the attribute calls were not, as they are specific to Haiku.
Initially I had completely forgot about them, and it wasn't until a few days
later when I noticed that I had an "attributes" directory in my generated
that I realized that the "generic" attribute layer was being used on Haiku.
I attempted a fix for this in 5e19679ea3,
thinking that would clear the problem up, but I didn't actually run a test
beyond seeing that my BuildConfig had been updated properly. In fact,
BuildSetup was hard-wired to not even pass that definition through on
Haiku, and so that commit had in effect caused nothing.
My initial "fix" of just changing BuildSetup then caused a build failure,
as while libroot_build itself compiled, it ran into errors whenever attributes
were used, because in letting the real libroot's attribute calls shine
through, I had bypassed libroot_build's FD emulation/shim layer.
Then I tried and failed at three separate attempts to solve this with code:
- a version of the "fs_attr_...h" interface for Haiku. This proved possible
in theory, but in practice I would need to reimplement a lot of attribute
handling code in it, because all I had access to from there was syscalls.
- a version of "fs_attr_untyped" that bypassed its reimplementations of
the "fs*attr" functions for the libroot ones, only using the FD shim layer.
This proved possibly not even theoretically possible because it would have
caused preprocessor hell in some of the build headers, and also assumptions
about how attributes are read were totally different.
- a completely new "fs_attr_haiku" that was a completely new interface to
the fs*attr functions. This proved practically impossible because of the
need to include structures from the system libroot to call out to readdir,
etc. that attempts to solve would also have caused preprocessor hell.
Then I realized that the Linux xattr emulation library, which I'd used
as a reference when attempting the first solution, was shipped by default
as a system library in all builds of Haiku ... and so I could just tell
fs_attr_untyped to use the Linux xattr handler, and then link against libgnu.
So that is how I arrived at this strange and decidedly unorthodox solution
to a problem of my own creation.
Per #10267, "Most (ported) third-party software should be removed
from the Haiku source repository."
Since HaikuPorts already has the ncompress package, this file
should no longer exist.
Signed-off-by: Augustin Cavalier <waddlesplash@gmail.com>
Original patch missed modifying the "minimum" definition and the
src/bin/Jamfile, so I took care of that.
- Recent changes to the build system appear to make the assumption
that the GNU regex APIs are universally available. This isn't the
case on FreeBSD, which requires libgnuregex to provide that
functionality. This broke the host keymap build.
gnuefi package was replaced by gnu_efi_kernel, but build
was not updated. This is guesswork, as I couldn't track down what changed.
It finds headers, headers_arch and lib and works so should be ok.
It was needed on macOS for a time when BUrl used regexes for parsing.
Now it does not, and so we can remove libshared's RegExp from build
libshared, and thus also libgnuregex.
I wrote this back in 2010 as my first driver project.
Reasons to remove it:
* The license is GPL
* Current WiMAX hardware is generally WIFI based.
* It controlled the hardware, but never worked
for network access since we need SSL certs and stuff
which vendors weren't too open with.
* WiMAX kind of died (at least in the US)
I left the wwan directory, it would be a nice spot
for CDMA / GSM dongle drivers.
Previously we just used the system libroot, which of course meant
that when libroot's ABI changed, the build broke. Now we use the full
libroot_build that we do on non-Haiku platforms. The logic for "BeOS-compatible
but not Haiku" does not really apply anymore, so it has been gutted where
appropriate (and libhaikucompat has been decoupled from the build.)
The only caveat here is the change to Errors.h -- we really should be using
the system's one where I included the one from the tree, but for whatever
reason, GCC2 refused to handle the #include_next properly.
Fixes the build breakage of Haiku-on-Haiku by my prior commits (sorry).
Previously --update was kind of a hack, as it just dumped all
the variables from BuildConfig back into ./configure and attempted
to rerun from there.
Instead, now we store all of the variables and environs configure
was invoked with in the top of BuildConfig and re-call it using them.
This is much more robust, as configure will actually recompute
all of the values from the BuildConfig.
As a side effect, if configure was originally invoked to build crosstools,
it would have done so again, so instead add a check to see if they
exist, and skip them if they do. It's easy enough to delete the
directory if you want to force a crosstools rebuild.
Briefly discussed with mmlr on IRC.
Instead build the one in-tree from src/data/package_infos/. Fixes the
"HaikuPorts repos have wrong URL" problem that has occured since the
switch to buildmaster repos.
When compiling with GCC, these headers get pulled in from the
gcc_syslibs_devel package, but we cannot do something similar
for Clang as Clang adds/removes internal builtins used by
the headers nearly every version. So instead we just copy
all the intrinsics headers from current Clang into generated,
and make sure this directory is included before any others.
* Actually locate the clang executable, and allow user overrides
* Properly preserve arguments in get_build_tool_path
* Fix get_build_tool_path for commands with dashes (e.g. "clang-5.0")
* Update repository file to hardlink_packages modified one.
* Add some basic process overview to directory.
* We don't normally document in paths, but this stuff is complex.
* Documentation improvements welcome.
* Hashing semantics for the new build repositories are different than
the old ones, so update those (if the x86 build was not broken before
it is now...)
* OptionalPackages has been updated slightly (removed libtool and git_cvs
from the default images, as they are rarely used nowadays and would pull
in a bunch of dependencies we don't really care for either)
* Removed lib:libqrencode from Haiku package requires (qrencode_kdl is a
static library, the userland libqrencode is not used anywhere in the tree,
as far as I can tell)
* Fix build of JPEG2000 translator after update
* Decouple fluidsynth build machinery and remove from image now that it
is no longer used
* Update repository URL in Repositories preflet
x86 is unaffected, as already mentioned. This breaks the build,
but since this diff was large, I wanted to have the functionality
changes be clear, so they are in the next commit.
The packages that remain are only the ones used somewhere in Jam
(including ones off by default, e.g. Wonderbrush, Live555.)
The x86 repo is untouched as it is being phased out and has no buildmaster-
generated equivalent.
It was trying to use $(feature:U) outside of the loop where it is
actually set. Thanks to PulkoMandy for spotting the problem.
(How did this not break tons of stuff?)
libmedia.so was used by at least 2 apps included in the minimum image,
Activity Monitor and Deskcalc which subsequently failed to load on minimum.
Deskcalc wasn't actually using libmedia.so so I managed to get it to link and
run on minimum, however, Activity Monitor is using libmedia.so so needed it
to be present.
To fix this I added libmedia.so to the minimum image, I hope this does not blow
its size budget. (adds 1.0MB)
* Previously, the cross-compiler would generate code that doesn't
run on Haiku, particularly where TLS is concerned. It also ended
up with a c++config.h header incompatible with the version in
the native compiler.
* Now possible to correctly cross-compile rust for Haiku.
Among other fixes and more translations, there's now an "Import"
feature to merge in another catkeys file.
Handy when the en.catkeys changed and you want to import the translated
catkeys file for the previous version, which already contains the
translations for the strings that haven't changed.
Hmm... hope what I wrote there is decipherable...
No longer used by anything (it appears some old kernel drivers that
are not included in the build might use it, but I don't know why
they need it -- we already ship GPL'd code [libntfs] for the kernel
in the default build unconditionally.)
Briefly discussed with js a few weeks back.
