Make devkitARM optional

[froggestspirit]

This change should not affect anyone currently using devkit. This should enable users to compile without devkit if the arm-none-eabi compiler is present.

Tested working on Windows by Kurausukun with devkit installed Tested working on 64-bit Debian by FroggestSpirit without devkit after running "sudo apt-get install gcc-arm-none-eabi binutils-arm-none-eabi"

[fincs]

Please don't do this. $(DEVKITARM)/base_tools is the officially supported way to set up the target triplet and the names of the various binaries that are involved in cross compilation. This was originally suggested by us a year ago, see https://github.com/pret/pokeemerald/commit/489f90b8324d3e395d41e94a0d97f2b39463854e and https://github.com/pret/pokeruby/commit/97a933ceeaa1f360eea4322b8e8b47b200ad0fe2. Projects not using this file might find their buildsystems broken by future devkitARM updates.

Users will find that, in general, devkitARM is preferable to random generic arm-none-eabi toolchains shipped by distros; because it includes a heavily customized newlib that allows for many kinds of code expecting a POSIX-esque environment to work unmodified. On top of serving as a drop-in replacement for said toolchains, it also provides first-class support for building code that runs on many ARM based Nintendo consoles, including the GBA, DS(i) and 3DS.

[PikalaxALT]

We have a separate fork that builds binutils targeting arm, rendering this pr redundant.

[aaaaaa123456789]

@fincs devkitARM also violates the GPL (I'd point you to my comment on an issue in the repo, but someone there helpfully deleted it as "anonymous trolling" and closed the issue, so no luck), which has made several users uneasy about using it.

And besides,the projects using agbcc use none of the "POSIX-esque environment" you mention — in fact, the first step to build those projects is to exclude any libc implementation from the build, rendering that point moot.

[mid-kid]

devkitARM also violates the GPL

Why would someone go on the internet and tell lies? The issue with the licensing of the crt0 files has been resolved and having a reserved trademark does not violate the GPL.

[aaaaaa123456789]

@mid-kid Correct me if I'm wrong, but I believe the issue with the build scripts stands unresolved.

[mid-kid]

https://devkitpro.org/wiki/Trademarks#Trademarks_and_the_GPL

[aaaaaa123456789]

I'm not referring to trademarks. I'm talking about this:

https://github.com/devkitPro/buildscripts/blob/master/build-devkit.sh#L17

Forbidding redistribution of build scripts violates the GPL.

[mid-kid]

That line quite literally refers to the trademarks.

[aaaaaa123456789]

It doesn't. "...may not be distributed by entiries other than devkitPro" is a restriction on distribution, not a (perfectly valid) restriction on trademark usage. It doesn't say that you can redistribute them if you change the name. It says you cannot do it at all.

[mid-kid]

Also, actual suggestion: Since the devkitarm binaries might not work on certain platforms if you don't include build_tools, what about checking for the presence of the $(DEVKITARM) variable and including the file if it's there?

[fincs]

@aaaaaa123456789 please stop actively spreading hurtful misinformation about devkitPro and the software devkitPro produces. The licensing of buildscripts has nothing to do with licensing of the software built by the buildscripts.

[aaaaaa123456789]

@fincs But the license used by the software built by the build scripts requires that the build scripts are covered by that license. It's in the GPL.

[fincs]

That is such a ludicrously weird claim. I can't see anywhere in the GPL that shell scripts that have commands for building GPL software must also be licensed as GPL.

Also, this PR discussion has been pretty heavily derailed. It would be appreciated if a moderator of this organization could clean it up.

[aaaaaa123456789]

@fincs GPLv3, in Section 1: "The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities." (bold is mine)

Needless to say, all requirements regarding licensing and distribution of source will therefore include said scripts.

[froggestspirit]

For what it's worth, we could do what I set up in the pull request for pokeemerald, where if DevkitArm is defined, it essentially ignores my part and still looks for the include file. This was only because getting devkit on my machine was difficult vs the arm compilers

[fincs]

@aaaaaa123456789 That refers to the buildsystem of GCC itself, which is autotools and unrelated to the buildscripts we use to set up devkitARM and the other toolchains. If we take your claim at face value, then all tutorials and shell scripts that show how to set up a GCC cross compiler are also in violation of the GPL because they are not licensed under a GPL compatible license.

@froggestspirit If you encounter problems setting up devkitARM on your machine, feel free to request assistance. The devkitPro forums as well as the IRC channels can be used to reach us. There's also the Getting Started guide, which also explains what you need to do to set up a working toolchain.

[aaaaaa123456789]

@fincs So you're saying that devkitARM is not a derivative work of GCC and whatever other GNU tools you're using as part of the toolchain? Because that would be quite a hard claim to hold.

And if they are derivative works, they must conform to the license of the GNU software they include, which requires relicensing the whole work under the same license. And that same license requires including the build scripts in the source that can be distributed and modified freely.

[froggestspirit]

It's not just the setup, but that I didn't really need the overhead. I'm working on my project on a Raspberry Pi (personal choice, but I got it running fine). I don't really need the library just for the one time agbcc compile and the subsequent compiles for pokeemerald. I know this is a very situational case, but my goal was to essentially make it not change anything for people that do use devkitarm

I've updated the makefiles to still use the devkit "build_tools" file if DevKitARM is set as an enviroment variable, otherwise it will fallback to seeing if the compilers are available. (Also, I didn't mean for this to blow up, I figured it could help in some circumstances.)

[fincs]

@aaaaaa123456789 I really don't know where you got that from. I'm only talking about the buildscripts, which are internal scripts we use for building the toolchains (essentially automating the various patching/configure scripts you need to run to build a GCC cross-compiling toolchain), and we offer them to the public mainly as a courtesy so that people who cannot use the official binaries can still get their own copy of the toolchains built for their system. devkitARM and the other toolchains, as GCC+binutils+newlib bundles, are still licensed under the individual licenses for each component. The fact that the names of our software are trademarked doesn't change this fact. As an example of a similar arrangement, the name of Firefox is owned by Mozilla and only Mozilla can release software under this name, but the software itself is licensed under a free software license. This is to prevent abuse from 3rd parties who might be redistributing old versions of toolchains we don't support, or other software that is not associated with us misleadingly under our name.

@froggestspirit At some point we have considered distributing Raspberry Pi/Raspbian builds of the toolchains, but we are not sure if there's any public interest in them that would make them worthwhile to build. Still, noted.

[aaaaaa123456789]

@fincs You'll notice I made no complaints about the trademark — your standpoint is very reasonable in that regard. On the other hand, if the toolchain is GPL'd, then the build scripts for the toolchain cannot be internal and cannot have restrictions on distribution, as I showed you a few comments above. You can restrict the usage of the name, but not the distribution of the scripts themselves.

And yes, I'm well aware that the scripts automate the building process. That's what scripts do. That doesn't make them any less covered by the definition of "corresponding source" posted above. And as such, they must abide by the terms of distribution imposed by the GPL.

(Also, note section 5(c) of the GPL, regarding modifications: "You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged.")

[mid-kid]

In layman's terms, the line in the file linked in a comment above is worded incorrectly and should be modified in order to properly reflect that you may not distribute toolchains under the same trademark.

[fincs]

@aaaaaa123456789 The buildscripts are not part of the GCC source code and they are functionally equivalent to a guide showing how to compile a GCC cross-compiler from scratch (there are many guides out there about this). We could have instead published a document about which tarballs to download, which commands to use, which flags to pass to configure, etc; but we chose instead to publish scripts that do that directly precisely because it's more convenient. The intended target audience of these scripts are people who need to get the toolchains running on a system we don't support. This isn't a basis for people to argue about nonexistent licensing issues that take time away from the development of the toolchains.

[aaaaaa123456789]

@fincs It would take less than five minutes to fix the build scripts to contain GPL-compliant text (something like "if you distribute or modify these scripts in any way, you may not use the name devkitPro or any related trademarks to designate the resulting toolchain") should do the trick. You came unannounced to a random repository advertising how we shouldn't use any alternatives to your toolchain — clearly you have that much free time. This has never been about the hypothetical time you'd spend on the debate or on the fix.

I'm well aware that the build scripts are not part of the GCC source code. They are build scripts. You're not saying anything new there. You keep posting the definition of a build script over and over in various rewritten forms in an attempt to convince me that they are not part of GCC — which is not what I'm claiming. The definition of "Corresponding Source" as given in the GPL includes scripts that control the process of building the source code. That's what your build scripts do.

And as such, they must be distributed under terms that comply with the GPL.

[fincs]

@aaaaaa123456789 You have crossed the line into personal attack, which is an ad hominem fallacy. As a devkitPro developer, it is our duty to see how our users are doing, and assist/advise them on the best way to use our products. Moreover, I have personal interest in the pret project, so therefore I have extra interest in ensuring that they use devkitPro products in a way that will allow them to benefit from the best experience they offer.

Your argument simply doesn't hold. If we take your claims at face value, we'll come to the conclusion that pretty much every tutorial, document or script that shows how to build a GCC-based toolchain is a violation of the GPL. This includes all sorts of guides and scripts and even popular distros' GCC packages. Not to mention that it would also apply to any tutorial, document or script that at some point or another involves building a GPL licensed piece of software. I can't see this as anything other than a perversion of the spirit of the GPL. In addition, you are contradicting yourself by being aware that the buildscripts aren't part of the GCC source code, then at the same time talking about "Corresponding Source" and scripts that control the process of building the source code which, in this context, exclusively applies to the actual build system used by GCC which is none other than the series of autotools-based scripts that govern the GCC build process.

[PikalaxALT]

Back to the issue at hand, the changes proposed to agbcc are insufficient as they provide no guidance on how to set up a non-dkP arm toolchain. I'll defer once again to @luckytyphlosion's branch which is derived from @easyaspi314's effort to replace dkP with a minimal subset of GNU binutils.

[mid-kid]

This patch simply helps with providing the option of using your system vendor's arm-none-eabi- binutils. As such, the installation process depends on what distribution you're running on. If said distribution is devkitpro/msys2, then you already know how to :wink:

This patch is to no detriment for existing devkitarm users. Besides, building binutils for this isn't any harder than ./configure --target=arm-none-eabi, as can be read in the devkitpro buildscripts.

Building agbcc and the decomps shouldn't require a custom binutils if we can avoid it. If anything, purely for compatibility's sake.

[mid-kid]

Also, I think it's worth re-stating, since it seems to be a common misconception, that devkitpro isn't a toolchain in and of itself, but rather merely a distribution of fully free components comprising of the GNU binutils, GCC, newlib, pacman, and various libraries and utilities related to building software for the devices we all know and love. You can take devkitpro apart into its components VERY easily, made even easier by the rather recent addition of the pacman package manager

Pret mostly only needs the binutils, since the C compiler is provided by agbcc, and the rest of the utilities are built in the repos themselves. It makes sense to only want users to install binutils, but there's a lot of ways to go about that. Keep the options open.

[fincs]

devkitPro isn't a distribution of components. devkitPro is an organization that produces and distributes those components. You can't "take devkitPro apart", that involves taking people apart. From our wiki:

Please note: devkitPro is the organisation that provides the tools. We are not a software package, we don't have version numbers and the only way to have us compile your code is to pay us (or maybe if you ask nicely when you need help figuring out an issue)

https://devkitpro.org/wiki/About

devkitPro is an organisation dedicated to producing a number of cross compilers intended for use by hobby programmers writing their own games and applications for popular games consoles where it's possible to run unsigned code. The goal is to provide amateur programmers with the means to program for resource limited devices and so gain valuable experience which would transfer well to a career in game development.

[mid-kid]

If devkitPro isn't the name of the distribution, then what is the distribution called? Simply "devkitPro's distribution"? All I'm saying is that you can take the distribution apart.

[fincs]

We usually refer to our software as "the tools and libraries". Any wording that makes it sufficiently clear that "devkitPro" is not the name of the software, but the name of the people who make the software, should be sufficient.

[WinterMute]

It's not just the setup, but that I didn't really need the overhead. I'm working on my project on a Raspberry Pi (personal choice, but I got it running fine). I don't really need the library just for the one time agbcc compile and the subsequent compiles for pokeemerald. I know this is a very situational case, but my goal was to essentially make it not change anything for people that do use devkitarm I've updated the makefiles to still use the devkit "build_tools" file if devkitARM is set as an enviroment variable, otherwise it will fallback to seeing if the compilers are available.

Being honest if we do change the triplet again in the future it will most likely be because there's a new standard triplet being used for bare metal so I'm not sure I'd bother with the conditional include vs setting triplet manually as you did originally. The main advantage of including base_tools from devkitARM is that it adds both the toolchains & supplementary tools to the path. Given that these pret projects don't use specific devkitARM functionality and the goals are a bit different from the devkitPro toolchains ( which is why I suggested building such an old gcc version for these projects originally) and we haven't yet provided binaries for Raspberry Pi there's no compelling reason to insist that devkitARM should be used here, especially considering that the primary dependency is arm-none-eabi binutils.

(Also, I didn't mean for this to blow up, I figured it could help in some circumstances.)

Unfortunately some people are engaged in some kind of vendetta and I can only apologise for the horrific trolling on this issue and hope that it doesn't put you off contributing in the future. This is precisely the kind of behaviour that gives the GPL a bad name and has no place on this issue or indeed anywhere.

Also, I think it's worth re-stating, since it seems to be a common misconception, that devkitpro isn't a toolchain in and of itself, but rather merely a distribution of fully free components comprising of the GNU binutils, GCC, newlib, pacman, and various libraries and utilities related to building software for the devices we all know and love.

No. devkitPro is the organisation that provides and maintains a carefully curated set of tools and libraries which allow easily building software for the devices we know and love. devkitPro is not software, devkitPro is not a collection of software. A lot of work has gone into making our tools what they are and we'd appreciate a little respect for how much easier homebrew development is with them.

[mid-kid]

A lot of work has gone into making our tools what they are and we'd appreciate a little respect for how much easier homebrew development is with them.

I respect the work that has gone into making the toolchain. All I was trying to say is that a big chunk of the tools (I am very well aware this doesn't apply to all of them) included in the toolchain can be used in the same way when provided in a standalone fashion, and as such would be no different than using a different distro's tools, which is rather relevant in the issue at hand, and to supply my argument for supporting the usage of devkitpro's tools as well as others.

I am sorry if this came across as disrespectful, that wasn't the intent behind my words.

EDIT: Wasn't there a problem with needing to define PATH properly to find a DLL in the windows version of devkitARM, for which it would be best to just include base_tools?

[WinterMute]

If devkitPro isn't the name of the distribution, then what is the distribution called? Simply "devkitPro's distribution"? All I'm saying is that you can take the distribution apart.

Many of the tools and libraries we supply are dependent on each other and taking our software apart is ill advised and will cause issues for other people.

Personally I'd rather you just merged the original commit and banned the trolls. This endless circular debate about what devkitPro is or isn't gets very tedious and tends to attract trolls. It doesn't serve any purpose here and I'm sorry that we attract it.

The simple fact is, we've successfully constructed and maintained tools and libraries for a variety of Nintendo consoles in a manner that makes it very easy for people to get on with building code. Sadly that's not good enough for some people and they seem to think it's a good use of their time to attack us in every available forum. I gave up engaging with them some time ago, they don't appear to be doing this in good faith but rather engaging in the kind of GPL zealotry that puts people off dealing with anything that's remotely connected with GPL code.

[huderlem]

@WinterMute @fincs Thank you for your inputs here--I am also frustrated with the circular debating about seemingly-minute GPL semantics. Your final suggestion for removing the base_tools include seems like the best path for this agbcc project, since it only depends on binutils.

@froggestspirit Would you mind reverting back to the initial change you had?

[WinterMute]

@huderlem @froggestspirit

Actually, it might be better to have your own base_tools makefile fragment in the root here & include that in both makefiles rather than having two places to edit if needed in the future. Not sure it's likely the triplet will change again but you never know.

[froggestspirit]

@Huderlem I'm fine with whatever seems to be the best decision, just let me know if I should revert this or if it should be as a separate include. @WinterMute I appreciate the input, Ive been working on a 64bit debian build for Pi, so im not sure if that might be helpful in the future for devkit. on an unrelated note, i apologize if I did something wrong on twitter to be blocked (removed the emojis from my name)

[huderlem]

@froggestspirit The separate include seems overkill--let's just go with the original commit.

[huderlem]

It seems I was misunderstanding how the devkitpro installation works. I was thinking that simply installing devkitpro was placing the tools on the path, but that is obviously not how it works (including base_tools is how you get those on the path). This means that the conditional devkitarm check would need to be used, after all.

The devkitarm check is helpful because it doesn't require users of pokeemerald/ruby to install devkitarm AND install these additional non-devkitpro tools just to compile agbcc.

[WinterMute]

Yeah, fair enough. We don't add the toolchains to the the path by default to avoid interference with other arm-none-eabi tools and base_tools adds to front of path so it all works as expected when system arm-none-eabi tool packages are installed. @mid-kid's point about dlls is also relevant for windows users.

I thought you might be adding tools to path before building but depending on path/base_tools is probably as good a way as any to go.

[rawr51919]

We have a separate fork that builds binutils targeting arm, rendering this pr redundant.

How up-to-date is said fork, anyway? Also, would this still be relevant to do? Looks like this PR has caused a firestorm in the past, so let's hope we keep that to a minimum now.

[mid-kid]

That fork is relatively up-to-date (binutils itself is outdated though), but doesn't work properly on some systems so it hasn't yet been merged into this repo. I'd say this PR is still relevant while we haven't fully switched to a standalone binutils.

[rawr51919]

That fork is relatively up-to-date (binutils itself is outdated though), but doesn't work properly on some systems so it hasn't yet been merged into this repo. I'd say this PR is still relevant while we haven't fully switched to a standalone binutils.

Would be worth looking into that before we consider either this PR's content or the fork. We could use the PR as a stopgap while that fork's in development.

[luckytyphlosion]

Probably fixed by #37