summaryrefslogtreecommitdiffstats
path: root/Utilities/cmbzip2
Commit message (Collapse)AuthorAgeFilesLines
* bzip: Precompile common expensive headersClemens Wasser2023-06-221-0/+4
|
* bzip2: Suppress clang-analyzer warningsBrad King2023-05-222-0/+12
|
* Utilities: Activate POSIX APIs even without compiler extensionsBrad King2022-06-041-0/+8
| | | | | | | | | | | Compile some third-party libraries with preprocessor definitions that activate POSIX APIs even when compiler extensions are not enabled. We already do this in libuv, inherited from the upstream buildsystem. This extends commit f034b0f663 (CMake compilation: do not use compiler extensions, 2020-03-14, v3.18.0-rc1~494^2). Issue: #20454
* Utilities: Suppress warnings in third-party code with IBMClangAaron Liu2022-01-271-1/+1
|
* LCC: Add dedicated support for MCST LCC compilermakise-homura2021-10-151-1/+1
| | | | | | | | | | | | | | | | | | | | | Divert LCC compiler as a new one, instead of treating it as GNU. Since old times, Elbrus C/C++/Fortran Compiler (LCC) by MCST has been passing checks for GNU compilers, so it has been identified as GNU. Now, with intent of seriously upstreaming its support, it has been added as a separate LCC compiler, and its version displays not a supported GCC version, but LCC version itself (e.g. LCC 1.25.19 instead of GNU 7.3.0). This commit adds its support for detection, and also converts basically every check like 'is this compiler GNU?' to 'is this compiler GNU or LCC?'. The only places where this check is untouched, is where it regards other platforms where LCC is unavailable (primarily non-Linux), and where it REALLY differs from GNU compiler. Note: this transition may break software that are already ported to Elbrus, but hardly relies that LCC will be detected as GNU; still such software is not known.
* Utilities: Suppress warnings in third-party code with NVHPCBrad King2021-04-201-1/+1
|
* Utilities: Suppress warnings in third-party code when using IntelLLVMBrad King2021-01-281-1/+1
|
* bzip2: Disable MSVC warnings in 3rd party codeBrad King2020-02-251-1/+3
| | | | | In commit 35acaa90c5 (bzip2: Add compilation flags to disable warnings in third-party code, 2020-02-24) we forgot to disable warnings for MSVC.
* Merge branch 'upstream-bzip2' into update-bzip2Brad King2020-02-2416-84/+100
| | | | | | # By bzip2 upstream * upstream-bzip2: bzip2 2019-07-13 (6a8690fc)
* bzip2: Add compilation flags to disable warnings in third-party codeBrad King2020-02-241-0/+9
|
* Merge branch 'upstream-bzip2' into update-bzip2Brad King2020-02-2418-0/+8350
| | | | | | # By bzip2 upstream * upstream-bzip2: bzip2 2007-12-10 (a1d78c55)
* bzip2: Remove all sources to make room for fresh importBrad King2020-02-2457-159717/+0
|
* bzip2: Drop unused .dsp filesBrad King2017-08-302-223/+0
|
* curl, bzip2: Suppress warnings by setting initial valueSean McBride2013-10-081-1/+1
| | | | Silence clang -Wsometimes-uninitialized warnings.
* BZip2: Remove unnecessary *.bz2 files from CMake source treeDavid Cole2012-06-133-0/+0
| | | | | | | We had complaints that people couldn't install the CMake source tarball on some secure systems because there were "corrupt bz2 files" in it... We do not use these sample*.bz2 files anyhow in the CMake build, so we'll just remove them.
* Suppress -Wcast-align in curl and bzip2Brad King2010-09-101-0/+3
| | | | Trust upstream developers of third-party code.
* suppress another warning.Bill Hoffman2009-11-121-0/+2
|
* Remove a few more warningsBill Hoffman2009-11-101-0/+6
|
* Remove makefile as it breaks in-source build testingBill Hoffman2009-11-061-217/+0
|
* bzip2: Restore fix for unused variablesBrad King2009-11-041-0/+3
| | | | | | The commit "bzip2: Disable Borland warnings" accidentally reverted changes from commit "Fix warnings for unused variables". This restores them.
* bzip2: Disable Borland warningsBrad King2009-11-042-3/+6
| | | | | We disable warnings to silence them while making minimal changes to third-party code.
* Fix warnings for unused variablesBill Hoffman2009-11-031-0/+3
|
* Switch to using libarchive from libtar for cpack and cmake -E tarBill Hoffman2009-10-3064-0/+160141
This allows for a built in bzip and zip capability, so external tools will not be needed for these packagers. The cmake -E tar xf should be able to handle all compression types now as well.