autogen.sh missing from release tarball #4997

issue jgarzik openend this issue on September 28, 2014
  1. jgarzik commented at 4:04 pm on September 28, 2014: contributor
    Build instructions reference autogen.sh, but autogen.sh is not included the source code tarball, that is included in the 0.9.3 release.
  2. laanwj added the label Build system on Sep 29, 2014
  3. laanwj commented at 7:21 am on September 29, 2014: member

    For tarball builds you can skip the autogen.sh stage. But yes, it should be included in case people want to make changes.

    This is one of the many files that people purport missing, I’ve already proposed many times to just build the tarballs from the git repository directly instead of trying to micromanage which files to include.

  4. jgarzik commented at 11:33 am on September 29, 2014: contributor
    @laanwj “build instructions[…]” Or just fix the doc. The goal is simply to fix user confusion. That doesn’t mean we need to ship autogen.sh, just give accurate instructions for the tarball.
  5. laanwj commented at 11:48 am on September 29, 2014: member
    But we do need to ship it. It’s required in case someone wants to change the build system.
  6. TheBlueMatt commented at 8:53 pm on September 30, 2014: member
    Do other projects ship autogen.sh? In any case the doc shouldnt mention autogen.sh whether we ship it or not (as long as we ship configure)
  7. theuni commented at 9:00 pm on September 30, 2014: member

    I’d say about 75% do. Personally, I get irritated when they don’t because as @laanwj said, it can be needed downstream when patching a project’s configure. Though, 99% of the time when that happens, an autoreconf -vif works fine (it would in our case as well).

    +1 for adding it though. I’ll PR it.

  8. jgarzik commented at 9:00 pm on September 30, 2014: contributor

    The standard autotools-generated behavior is to create a tarball that does not include autogen.sh, and does include a fully prepared configure. The build machine (executor of ./configure) is not typically required to have autotools. autotools tries to minimize what dev tools are required. make distcheck tarballs do not include it. </general principle>

    Feel free to deviate from the standard, if there is logic and downstream benefit…

  9. theuni commented at 9:12 pm on September 30, 2014: member

    @jgarzik Yep, I agree with your description. Here’s a realistic downstream benefit: We munge configure for some platform that isn’t often tested (say freebsd). If they can regenerate configure, they can patch the configure.ac and send us the fix. If they can’t, they’ll patch the generated one and be done with it.

    Again, in practice it wouldn’t really matter because our autogen.sh boils down to nothing more than an autoreconf. It’d just be a convenience for downstreams. I really don’t care either way, so I’m erring on the side of convenience.

  10. laanwj commented at 9:36 am on October 1, 2014: member

    @jgarzik autogen.sh is just a developer-added convenience. There is no standard general autotools-generated behavior about it. A lot of projects don’t even have one in the repository at all and rely on people calling autoreconf manually. It’s all up to us.

    (ie, make distcheck doesn’t include it by default because it doesn’t know about it… it could be called crazy_developer_script.sh and it’d be just as valid)

  11. jgarzik commented at 1:32 pm on October 1, 2014: contributor

    Of course. As stated, the general principle was being described.

    And we do want people to be able to build just using ./configure, as is standard.

  12. laanwj commented at 8:15 pm on October 1, 2014: member

    And we do want people to be able to build just using ./configure, as is standard.

    They have always been able to do this. Packaging a convenience script to regenerate configure or not doesn’t make a difference at all.

    I think you are confusing including configure scripts, which is useful for building without developer tools, and is standard, with excluding what is required to build configure. IMO that would be a bad idea, a tarball should be a just as valid starting point to make changes to the code as a git checkout.

  13. laanwj closed this on Sep 25, 2015

  14. MarcoFalke locked this on Sep 8, 2021

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2024-10-06 22:12 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me