in order to make builds reproducible.
See https://reproducible-builds.org/ for why this is good
and https://reproducible-builds.org/specs/source-date-epoch/
for the definition of this variable.
This date call only works with GNU date.
Also use UTC to be independent of timezone.
This is the equivalent of 6b260b87c3345568ebeddf57fbe95c864ee8baf2 for meson.
This PR was done while working on reproducible builds for openSUSE.
* Add --without-gperf configure flag
* Update sdb to support gperf.foreach and faster ls.sort()
* Support cc and types sdb gperfs
* add r_str_newvf
* Honor HAVE_GPERF in more places
* Add CI job to build and test cmds with gperf
This patch makes it possible to build with older version of meson.
It is needed to build radare2 on RedHat Enterprise Linux 8 where the meson version 0.49 is older than on RHEL7+EPEL7 or Fedora.
Issues fixed:
- set minimum meson version down to 0.49 (version available in RHEL8)
- meson 0.49 has bug which prevents processing of '\' split-lines => build r2_version_number on single line
- on meson 0.49 the ternary operator is not possible to use with some constructs (subdir in add_install_scripts) => replace one ternary operator with if-else construct
For projects that use radare2 as a subproject, allow OpenSSL to be
compiled statically into radare2 so the linker does not attempt to link
a dynamic library during static linking.
Co-authored-by: Keegan Saunders <meme@users.noreply.github.com>
* Windows, Linux, Static, macOS, Android, iOS builds published for every commit
* Kept coverage, coverity, fuzzing tests, lgtm and -Werror jobs
* Kill the continuos, the over-engineered matrix and other empty or unnecessary tasks (250 vs 900LOC)
* Jobs TODO: fatmac, termux and rpm (centos) packages
These fortunes make a lot of people unconfortable and can be trigering
for some. Even if they are not active by default, they should have no
place here if you are trying to be a welcoming project.
There are a lot of other ways to be quirky and fun, I see no logical
reason to have these fortunes knowing they will negatively impact
people.
Signed-off-by: Filipe Laíns <lains@riseup.net>