setup.nsi.in has "bitcoin" and "Bitcoin Core" hardcoded a lot #7265

https://github.com/bitcoin/bitcoin/blob/master/share/setup.nsi.in has the strings "bitcoin" and "Bitcoin Core" hardcoded in many places, even though those strings are available via autoconf. This makes it slightly more bothersome to change the name of the project, because changing the AC_INIT line in configure.ac isn't sufficient.

I don't know if this is something you want to fix in your repo, since it mostly only affects downstream projects like Namecoin. If you are interested in fixing this, I'd be happy to submit a PR.

To some extent, this is addressed by #7192. We do not aim to make altcoins easy, though, so "bitcoin" isn't likely to be un-hardcoded... (at least, I have no intention of doing it)

Also "bitcoin" is used in URLs and comments, and I don't think you can softcode those. Non-disruptive PRs are welcome, though.

We do not aim to make altcoins easy

That's anti-social. If someone wants to fork the client, rebrand it, but still use the same genesis block and consensus rules, I don't see the issue. Even if they plan on making an altcoin, part of open source is the freedom to change the things you disagree with.

Especially for things like MITcoin, which was a purely educational altcoin that never gained any momentum, nor was it ever intended to gain any moment.

I think there is some subtlety here.

I am opposed to actively making maintaining forked codebases harder. That is counterproductive for various reasons, including being usually against code cleanliness objectives, and making test deployments harder.

However, I also don't think there is an obligation to making forks' life easier where it implies a significant review, maintenance, or performance inpact on Bitcoin Core.

@DavidVorick

If someone wants to fork the client, rebrand it, but still use the same genesis block and consensus rules, I don't see the issue.

That is exactly what #7192 makes easier.

Even if they plan on making an altcoin, part of open source is the freedom to change the things you disagree with.

Sure, but that doesn't mean we need to go out of the way to make it easier. What @sipa said.

Especially for things like MITcoin, which was a purely educational altcoin that never gained any momentum, nor was it ever intended to gain any moment.

In such cases, I don't see a problem with just leaving everything labelled "bitcoins".

Hello,

I notice that I was a little bit vague; apologies for this.

First off, thanks @luke-jr for pointing out #7192 ; that's definitely helpful.

The specific issue I'm having is as follows:

Namecoin's build scripts generate Windows executable files such as "namecoind.exe" and "namecoin-qt.exe" rather than "bitcoind.exe" and "bitcoin-qt.exe". (I don't think this is specific to altcoins, since non-altcoin forks of Bitcoin Core may very well change these as well.) I'm not 100% sure where in the Namecoin build scripts "bitcoin" is changed to "namecoin" in the output filenames, but it seems to me that PACKAGE_TARNAME as defined in configure.ac's AC_INIT line is the logical place to do this. (If anyone disagrees, by all means correct me and tell me why I'm wrong.) In any event, Namecoin is successfully generating namecoind.exe and namecoin-qt.exe, but setup.nsi.in (which Namecoin hasn't modified from Bitcoin's codebase yet) has the filenames "bitcoind.exe" and "bitcoin-qt.exe" hardcoded, which causes the NSIS installer build step to fail. It seems to me that replacing "bitcoin" in those filename strings with a reference to PACKAGE_TARNAME would fix this. (Indeed, I tested such a change and it got Namecoin to build a working installer.) Certainly the Namecoin devs could just do a search/replace of "bitcoin" to "namecoin" in that file; that just seems kind of kludgy given that PACKAGE_TARNAME is available.

I'm definitely not asking about completely rebranding the UI to change "bitcoins" to some other currency unit. (While that would presumably be helpful for translations, i.e. not just altcoins, it's not the focus of this inquiry.)

Cheers.

I don't think autotools makes it practical to abstract the final binary names, unfortunately. Maybe @theuni can provide a more informed opinion though.

Is there a reason why PACKAGE_TARNAME is the wrong choice for this? Curious what @theuni thinks about this. (I'm not an autotools expert by any means, so I won't be surprised if I'm wrong.)

PACKAGE_TARNAME seems reasonable in places, the nsis script being one of them. At the time I autoconf'd that file, my intention was to make it completely generic using autoconf vars, but i decided to avoid changing too much at once as it might trigger this argument :)

So, no complaints from me as long as it doesn't cause us extra work.

Okay, sounds good. I'll submit a PR that uses PACKAGE_TARNAME in the nsis script, but I'll wait until after #7192 is merged so that risk of conflicts is reduced.

@JeremyRand #7192 was merged

Thanks for the reminder, I'll try to get on this soon.