LBRYCommunity/lbrycrd
1
0
Fork 0
Code Issues 29 Pull requests 1 Packages Projects Releases 32 Wiki Activity
The blockchain that provides the digital content namespace for the LBRY protocol
19703 commits 22 branches 42 tags 99 MiB
C++ 66.5%
Python 15.1%
C 12.7%
M4 2.1%
Makefile 1.2%
Other 2.3%
Go to file
Wladimir J. van der Laan b4fc5257b7
Merge #15456: Enable PID file creation on WIN 
3f5ad622e5 Enable PID file creation on Windows - Add available WIN PID function - Consider WIN32 in each relevant case - Add new preprocessor definitions to suppress warning - Update error message for generic OS (riordant)

Pull request description:

  # Introduction

  As discussed with @laanwj on IRC:

  - PID file creation was never enabled for Windows, as the `pid_t` filetype is not available for it. However, the WIN32 API contains the header [`Processthreadsapi.h`](https://github.com/CodeShark/x86_64-w64-mingw32/blob/master/include/processthreadsapi.h) which in turn contains the function [`GetCurrentProcessId()`](https://docs.microsoft.com/en-gb/windows/desktop/api/processthreadsapi/nf-processthreadsapi-getcurrentprocessid). ~~This function is called at a higher level by [`_getpid()`](https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/getpid?view=vs-2017)~~ EDIT: `_getpid()` is not available to the MSVC compiler used in the AppVeyor build. As a result, I have changed the function call to`GetCurrentProcessId()`, which performs the same function and is available to both MinGW & MSVC.
  This allows one to capture the PID in Windows, without any additional includes - the above function is already available.

  - Within this PR, I have added a separate line that calls `GetCurrentProcessId()` in the case of a WIN compilation, and the usual `getpid()` otherwise. All code blocks processing PID file logic that avoid WIN32 have been changed to consider it. I have also updated the preprocessor definitions in `libbitcoin_server.vcxproj.in` to suppress a warning related to `std::strerror` for the MSVC build, that was causing the AppVeyor build to fail (see @fanquake comment below).

  # Rationale
  - Consistency between OS's running Bitcoin
      - Applications which build off of `bitcoind`, such as novel front-end clients, often need access to the PID in order to control the daemon. Instead of designing some alternate way of doing this for one system, it should be consistent between all of them.

  In collaboration with @joernroeder

Tree-SHA512: 22fcbf866e99115d12ed29716e68d200d4c118ae2f7b188b7705dc0cf5f0cd0ce5fb18f772744c6238eecd9e6d0922c615e2f0e12a7fe7c810062a79d97aa6a2
2019-02-25 13:20:01 +01:00
.github Get more info about GUI-related issue on Linux 2018-12-27 06:53:07 +02:00
.travis qa: Add test/fuzz/test_runner.py 2019-02-13 17:12:28 -05:00
.tx qt: Pre-0.18 split-off translations update 2019-02-04 15:24:37 +01:00
build-aux/m4 Bump minimum Qt version to 5.5.1 2019-02-14 11:12:30 +01:00
build_msvc Enable PID file creation on Windows 2019-02-25 16:00:34 +07:00
contrib Merge #15273: docs: Slight tweak to the verify-commits script directions 2019-02-22 13:34:53 +01:00
depends Update zmq to 4.3.1 2019-01-18 10:25:14 +02:00
doc Merge #15222: docs: Add info about factors that affect dependency list 2019-02-21 09:59:15 +01:00
share [build] Makefile.am: add rule for src/bitcoin-wallet 2019-02-14 16:17:55 +01:00
src Merge #15456: Enable PID file creation on WIN 2019-02-25 13:20:01 +01:00
test Merge #15401: rpc: Actually throw help when passed invalid number of params 2019-02-25 09:31:08 +01:00
.appveyor.yml appveyor: Remove unused NDEBUG removal 2019-02-17 18:26:49 +08:00
.gitattributes Separate protocol versioning from clientversion 2014-10-29 00:24:40 -04:00
.gitignore [tools] Add wallet inspection and modification tool 2019-01-30 16:26:52 -05:00
.python-version [test] Travis: enforce Python 3.4 support in functional tests 2018-12-12 10:39:32 +01:00
.travis.yml Merge #15295: fuzz: Add test/fuzz/test_runner.py and run it in travis 2019-02-14 16:32:26 -05:00
autogen.sh Add "export LC_ALL=C" to all shell scripts 2018-06-14 15:27:52 +02:00
configure.ac Merge #15285: build: Prefer Python 3.4 even if newer versions are present on the system 2019-02-14 16:42:23 -05:00
CONTRIBUTING.md Botbot.me (IRC logs) not available anymore 2019-01-01 16:04:38 +02:00
COPYING [Trivial] Update license year range to 2019 2018-12-31 04:27:59 +01:00
INSTALL.md Update INSTALL landing redirection notice for build instructions. 2016-10-06 12:27:23 +13:00
libbitcoinconsensus.pc.in Unify package name to as few places as possible without major changes 2015-12-14 02:11:10 +00:00
Makefile.am Merge #15295: fuzz: Add test/fuzz/test_runner.py and run it in travis 2019-02-14 16:32:26 -05:00
README.md [doc] conf: Remove deprecated options from docs, Other cleanup 2018-11-07 13:30:03 -05:00

README.md

Bitcoin Core integration/staging tree

Build Status

https://bitcoincore.org

What is Bitcoin?

Bitcoin is an experimental digital currency that enables instant payments to anyone, anywhere in the world. Bitcoin uses peer-to-peer technology to operate with no central authority: managing transactions and issuing money are carried out collectively by the network. Bitcoin Core is the name of open source software which enables the use of this currency.

For more information, as well as an immediately useable, binary version of the Bitcoin Core software, see https://bitcoincore.org/en/download/, or read the original whitepaper.

License

Bitcoin Core is released under the terms of the MIT license. See COPYING for more information or see https://opensource.org/licenses/MIT.

Development Process

The master branch is regularly built and tested, but is not guaranteed to be completely stable. Tags are created regularly to indicate new official, stable release versions of Bitcoin Core.

The contribution workflow is described in CONTRIBUTING.md and useful hints for developers can be found in doc/developer-notes.md.

Testing

Testing and code review is the bottleneck for development; we get more pull requests than we can review and test on short notice. Please be patient and help out by testing other people's pull requests, and remember this is a security-critical project where any mistake might cost people lots of money.

Automated Testing

Developers are strongly encouraged to write unit tests for new code, and to submit new unit tests for old code. Unit tests can be compiled and run (assuming they weren't disabled in configure) with: make check. Further details on running and extending unit tests can be found in /src/test/README.md.

There are also regression and integration tests, written in Python, that are run automatically on the build server. These tests can be run (if the test dependencies are installed) with: test/functional/test_runner.py

The Travis CI system makes sure that every pull request is built for Windows, Linux, and macOS, and that unit/sanity tests are run automatically.

Manual Quality Assurance (QA) Testing

Changes should be tested by somebody other than the developer who wrote the code. This is especially important for large or high-risk changes. It is useful to add a test plan to the pull request description if testing the changes is not straightforward.

Translations

Changes to translations as well as new translations can be submitted to Bitcoin Core's Transifex page.

Translations are periodically pulled from Transifex and merged into the git repository. See the translation process for details on how this works.

Important: We do not accept translation changes as GitHub pull requests because the next pull from Transifex would automatically overwrite them again.

Translators should also subscribe to the mailing list.