checkblock.cpp invalid name for included datafile #10797

Closed
ko3ak opened this Issue Jul 11, 2017 · 6 comments

Comments

Projects
None yet
4 participants

ko3ak commented Jul 11, 2017

This issue tracker is only for technical issues related to bitcoin-core.

General bitcoin questions and/or support requests and are best directed to the Bitcoin StackExchange.

For reporting security issues, please read instructions at https://bitcoincore.org/en/contact/.

Describe the issue

Can you reliably reproduce the issue? Yes

If so, please list the steps to reproduce below:

  1. checkblock.cpp line 13 points to incorrect file name "bench/data/block413567.raw.h" data directory contains file "bench/data/block413567.raw"
    Line 13 should be changed from:
    12: namespace block_bench {
    13: #include "bench/data/block413567.raw.h"
    14: } // namespace block_bench
    to:
    12: namespace block_bench {
    13: #include "bench/data/block413567.raw"
    14: } // namespace block_bench

Expected behaviour

raw block should be included

Actual behaviour

unresolved inclusion error

Screenshots.

If the issue is related to the GUI, screenshots can be added to this issue via drag & drop.

What version of bitcoin-core are you using? git clone master 20170711

List the version number/commit ID, and if it is an official binary, self compiled or a distribution package such as PPA.

Machine specs:

  • OS: Linux
  • CPU: Intel
  • RAM: 8G
  • Disk size: 1TB
  • Disk Type (HD/SDD): SSD

Any extra information that might be useful in the debugging process.

This is normally the contents of a debug.log or config.log file. Raw text or a link to a pastebin type site are preferred.

Member

MarcoFalke commented Jul 11, 2017

ko3ak commented Jul 12, 2017

It was not very obvious '*.raw.h" is dynamically generated... When I was browsing bitcoin source code in eclipse I was seeing number of unresolved symbols. It would be better to have both files:
block413567.raw block413567.raw.h and regenerate as needed, rather than having unresolved symbols....

ko3ak changed the title from checkblock.cpp invalide name for incuded datafile to checkblock.cpp invalid name for included datafile Jul 12, 2017

Owner

laanwj commented Jul 13, 2017

I've never seen this error before.

How to reproduce this problem? (e.g. build steps that you enter from the shell, starting from a clean tree)

laanwj added the Build system label Jul 13, 2017

ko3ak commented Jul 13, 2017

  1. git clone https://github.com/bitcoin/bitcoin.git
  2. cd /home/bitcoin/src/bench
    [@fedora bench]$ grep raw .[ch]
    checkblock.cpp:#include "bench/data/block413567.raw.h" // file does not exists
    Note: browsing the source tree at this stage will produce errors as indexer cannot resolve include file, also, include file should be relative to location of .cpp when "..." is used i.e #include "data/block413567.raw.h"
    will this strategy of rebuilding include file from raw block work for Big Endian-Systems?
  3. cd /home/bitcoin
    ./autogen.sh
    ./configure
    make
    note: only after make source code can be browsed without errors related to missing include file
Owner

sipa commented Jul 13, 2017

In general, the git repository does not contain files that get generated during the build process anyway. Doing so means extra overhead in maintaining source and output to remain synchronized, and is confusing to people who want to modify the source.

Yes, if you want to browse auto-generated files, you'll need to build them.

Owner

laanwj commented Jul 13, 2017 edited

So there is no actual build system bug?
Going to close this.

Yes, if you want to browse auto-generated files, you'll need to build them.

It's the same for other generated files, for example configure Makefile etc. Checking in auto-generated files is usually a bad idea, as it can result in accidental diff noise if the generation isn't entirely deterministic (e.g. the file includes a date or such). It also makes git's scanning slower as the date metadata of the file will change on every build.

laanwj closed this Jul 13, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment