Collection of old devkitPro versions

Discussion in 'Wii - Emulation and Homebrew' started by leseratte, Dec 16, 2018.

  1. leseratte
    OP

    leseratte Wiimmfi Team

    Member
    6
    Jun 2, 2012
    Germany
    In the past, there have been multiple times where I wanted to compile a Wii homebrew and found out that my devkitPro / devkitPPC toolchain was either too old or too new to compile said homebrew. And getting the correct version of devkitPPC and libogc isn't always easy, because the DevkitPro-pacman installer only allows you to download the most recent one, and the old download links from sourceforge were removed earlier this year.

    According to the developers of devkitPro, the homebrew developers are supposed to fix their apps to work with new versions, and that devkitPro has no "versions" at all ( https://github.com/devkitPro/buildscripts/issues/29#issuecomment-406894916 ), but that is simply not practical for old homebrew that no longer has any maintainer.

    As neither the GPL nor the trademark of devkitPro prevent one from redistributing the old releases (as long as they are unmodified), I started collecting all the versions I can get and host them here: https://wii.leseratte10.de/devkitPro/

    I am now hoping that there are other people out here who might also have collected some older versions (especially Linux builds since I mostly have windows versions for the old devkitPPC versions). If so, it would be cool if you could send these to me (upload them somewhere and send me a link in a private message) so I can add them to my archive.

    Hopefully this can help a few people with compiling older homebrew which isn't adapted to the newest devkitPro version.

    Leseratte
     
    Sinon, Minox, Robz8 and 14 others like this.
  2. JacobM

    JacobM GBAtemp Regular

    Member
    3
    Jun 16, 2017
    United States
  3. leseratte
    OP

    leseratte Wiimmfi Team

    Member
    6
    Jun 2, 2012
    Germany
    Yes, I saw this thread, and already reached out to Cyan, Fix94 and fledge68 to get more older versions.
     
    JacobM likes this.
  4. tswntk

    tswntk GBAtemp Advanced Fan

    Member
    6
    Aug 6, 2012
    Switzerland
    what annoyed me (and everyone?) is the DCMA part
    I literally just abandon modifying Wii source codes and watch the Wii scene ...
    Well, he is the creator and the source for the booming of the Wii scene, he MIGHT have the right to destroy it.
     
  5. realWinterMute

    realWinterMute GBAtemp Regular

    Member
    4
    Feb 24, 2011
    You are in violation of our trademarks and the GPL. You can't provide binaries without corresponding source code, several of them were removed because we could no longer provide source so you certainly can't. Please remove these archives.

    It's better for everyone if projects are updated to compile with latest editions rather than forcing people to break their tools by mixing and matching old versions that may or may not actually work together.

    As I've said in other places we're more than willing to help get projects working with new tools if we can.

    Ultimately you're undermining the work we do to make homebrew accessible by causing major support headaches and wasting everyone's time with bugs that were fixed long ago or by not reporting new bugs to get them fixed.
     
  6. leseratte
    OP

    leseratte Wiimmfi Team

    Member
    6
    Jun 2, 2012
    Germany
    Hello WinterMute,

    first of all, this is not a trademark issue. A trademark is supposed to prevent others from making different products / things under a trademarked name. I am not doing that, as I am just redistributing official binaries. This is even written on the devkitPro Trademark page ( https://devkitpro.org/wiki/Trademarks ) - "Verbatim copies may be made without violating the devkitPro trademarks".

    If I am understanding the GPL correctly, source code for binaries older than three years no longer has to be provided as long as there are newer versions with the source code available, and for the newer versions, I am hosting source code.

    I do agree with your opinion that it is better for projects to be updated, and for new versions to be used for new projects. That is why I added the info text on my page saying that these old binaries are only to be used to compile old tools which are no longer maintained. If you have source code that nobody looked at in a few years which isn't maintained by anyone, then it can be difficult for users to get someone to update it just so it compiles with new tools. The old binaries hosted on the link above are only supposed to be used in this case, to be extracted in a self-contained folder, without "breaking tools by mixing and matching versions" (there is no mixing involved in downloading an old ZIP and extracting it somewhere), in order to compile old binaries.

    I also do understand that you do not want to provide support for old versions of the tools, and that is perfectly acceptable as well. But, time-wise, it shouldn't make a difference if you have threads like "where can I get old version X" and have to reply with "you can't get version X"; or if you instead have "hey old version X doesn't work" and have to reply with "we don't support version X".

    Other open-source projects don't remove old versions of their tools and they don't drown in support requests for old versions either. They just respond with "no longer supported, go update" and done. Both for support requests and for bug reports.

    On a completely unrelated note: I have read your blog post (https://davejmurphy.com/a-slightly-surreal-rant/) "A slightly surreal rant." - why can't that principle just apply here as well?
    If I want to clean my window using a cat (= compile old homebrew with old devkit), why can't you let me do that instead of trying to convince me to use a bucket of water and a squeegee (= making people use the new devkitPro releases)? I am not asking for help on window cleaning with my cat (= asking for support for old devkitPro versions).
     
    Last edited by leseratte, Dec 18, 2018
    Sinon, maorninja, Minox and 2 others like this.
  7. Cyan

    Cyan GBATemp's lurking knight

    Global Moderator
    22
    Oct 27, 2002
    France
    Engine room, learning
    do you have more help request for compiling old homebrew with old version of the toolchain (just tell users to update! don't waste time helping on compiling with old toolchain), or do you spend more time updating the old sources to let random users to compile old unupdated project with latest version?

    I noticed someone not happy with latest devkitA64, claiming switch homebrew became unstable and there's no way to revert back to the "just one" previous stable version to still compile the project properly until you fix and release the toolchain so he can update it.
    not having any version is to me hard to work with. I'd prefer a working station where you can easily revert back to the version you need rather than waiting for a future update to continue your project.

    I also don't see how you can spend time explaining how to compile old tools with old files, when the said project are already compiled correctly and without error on that old files. it's not a matter of "installing old devkitpro", but one of "keeping the one currently working" and by that you shouldn't have any request to fix something working, you might have one if the user decide to update his environment.


    as an example, I'm currently using an old devkitpro, with devkitPPC 29-1, which compile fine the project I'm currently working on. I don't need any help using that version, but I would need help once I choose to update. For now, I rather not update to not have to ask for help. I see the problem on the other side than you explain it. maybe I don't work like I should, but as long as it works, there's no reason to update. If I do, I'll have to update all old projects I want to compile, and I prefer an error free compile than spending time updating project which are not even mine and I don't know enough to spend time fixing if I'd updated devkitpro to pacman.

    I'm not against updating, I just don't want to spend time learning what has changed for now, because my current environment works. I'll update eventually, and when I'll do I'll need help. I don't need help now, and won't ask you to fix compiling old projects with old tools. that would be very bad move to ask a project maintainer how to use his outdated tools version.
    But I might need help when I'll update to pacman.
    For now, I'm not installing old tool, I'm using the one I have.

    I also understand that it's selfish because it forces someone else who want to work on my projects to have the same environment. having both an updated version would be easier.
    right now, leseratte had to find an old revision of my project which compiled fine on PPC_r27 to work on it, while I'm currently using with r29-1, because he couldn't find r29-1 for linux :/
    so he worked on an old version of my project, and I'll have to merge it and update it to compile correctly, while it could have been done directly with latest devkitPPC version if we both had updated to pacman.
    in that context, I understand that if my project was updated to compile on newest toolchain he could have just update his toolchain too. but then, he would have had to update all his old (maybe not even his own) projects to compile on pacman.

    But I didn't had time to learn what's required for latest version and fix the sources to compile on it.
    I also fear I won't be able to compile old, unmaintained project, which are not mine and I don't know anything about, without having to fix the sources to compile with pacman and updated portlib, etc.
    being abandonned projects, using googlecode, there's no way to participate and share updated sources for next, future, developer to work with. Any other developer will have to re-do that pacman update job for dead project while they could just compile using the version the project was aimed for.


    We don't want to install old tools just to keep using old ones, but because old project used them and might not work with updated sources. We don't try to use old project and ask you to fix errors with incompatible and conflicting libraries, we use the respective version of all required files.
    who would want to update sneek sources to compile with latest devkitARM ? it compiled only with devkitARM r32 !


    for now, I'm installing pacman on another computer to work on switch homebrew, and keep my old devkitpro to work on old wii homebrew on my main computer. (I know, env. variable can do the same)
    Personally, I'd prefer an environment with multiple fully sandboxed devkitpro+toolchain+prortlibs versions, and use environment variables to switch from one project to another.

    I'm willing to update and keeping my active projects up to date, it is better ! I just fear the (old) projects which are not mine will not compile anymore. Should we just give up on these old ones?
     
    Last edited by Cyan, Dec 18, 2018
    uyjulian, Minox, ahezard and 3 others like this.
  8. realWinterMute

    realWinterMute GBAtemp Regular

    Member
    4
    Feb 24, 2011
    You're providing devkitPro branded products and copyrighted code which isn't released under a permissive license.

    That's not how it works, no. You're obliged to provide sources for 3 years from the last availability of the binary. If you provide a binary then you have to also provide corresponding sources, you're also not allowed to just link to someone else's sources to fulfill that obligation.



    However providing old binaries mean that people don't even try. There have been several projects over the years on various platforms that built with newer tools just fine with relatively minimal changes to use newer functions and/or defines. Case in point, there were a huge number of DS projects that used the dual cpu templates for no reason & the arm7 side had bitrotted & no longer compiled. Converting those projects to a simple arm9 project using the default arm7 binary was the only change required.

    In other cases projects have become unmaintainable due to people ignoring the compiler warnings which newer compilers have occasionally turned into fatal bugs because function signatures were wrong. In these cases just fixing the warnings has been enough.


    This, more than anything, illustrates why providing these archives is short sighted and unhelpful. The tools and libraries have moved far beyond the early days of just being able

    The tools and libraries work together as a whole. Some versions of libfat work with some versions of libnds but not others. Both libnds and libfat work with some versions of devkitARM and not others. In some cases code built using unmatched versions of devkitARM/libnds/libfat will fail to build or fail to link. In other cases code will appear to build fine but have fatal bugs due to some change in the underlying ABI. Using the wrong default arm7 binary for the libnds version you're compiling with will also result in code just failing to boot.

    The same thing applies to devkitPPC/libogc/libfat.

    In some cases code built with unmatched versions of the tools & libraries will corrupt SD cards quite badly.

    The thing is, we'd much rather improve the experience.

    You don't understand the post.

    Providing archives of old releases with no understanding of how they fit together purely to avoid having to update code for newer tools is one of the things hinted at under the metaphor of "cleaning windows with a cat".

    Updating old projects for newer tools will teach you more about programming than simply recompiling a binary using the tool & library combinations that were originally used. Asking us for help with that process will help us to help you - we don't intend to break old code or prevent people from compiling old projects. If we don't know things are broken then we can't fix them.

    Teaching people to hunt for old tools and libraries instead of teaching them how to fix common warnings and update to newer APIs is teaching them to clean windows with cats. It's painful, inappropriate and rather cruel.

    Before devkitPro became a thing it was fairly common for people working on GBA homebrew to be completely incapable of collaborating on anything because there were several different tutorials of varying degrees of wrongness explaining how to build a toolchain and providing a bunch of magic numbers for hardware registers. Some of those toolchain instructions were turned into pre-built binaries with varying degrees of success. Windows centric instructions used bat files, linux often used shell scripts or makefiles. Some toolchains supported C++, some didn't. OSX users were generally left in the cold.

    The major thing we did was standardise the toolchain and the environment so that someone using our templates could take a project and compile it on linux, windows or OSX with no changes, everything was provided. This helped a lot with the emerging DS homebrew scene and allowed many more people to just get on with making homebrew instead of attempting to make sense of dozens of contradictory tutorials.

    It wasn't perfect but it was way better than it was before.

    We're continually updating and tweaking things too. Pacman is the best thing I've ever done and provides the means to obtain a standardised environment across the 3 main desktop OSes. We intend to improve things further but having to deal with users attempting to build example code and failing because they've followed some random tutorial instructing them to overwrite their initial toolchain install with old versions in order to compile some project that hasn't been updated in years takes a load of time away from improvements we want to make.

    Sure, we could just say we can't help them but the truth is if they remove the broken toolchain installation & redo it using pacman then all the example code works and they can get back to learning something instead.
     
  9. realWinterMute

    realWinterMute GBAtemp Regular

    Member
    4
    Feb 24, 2011
    Switch homebrew is relatively new, we expect teething troubles and various things to change as the console gets reverse engineered. There are all sorts of factors in play which result in issues but really it's impossible to comment on something we haven't been informed of. We provide what support we can on the devkitPro forums and in #switchdev on efnet. If you go elsewhere with problems then we're not responsible for the advice you get.



    No you're not. devkitPro is an organisation dedicated to providing & maintaining homebrew toolchains and libraries. You wouldn't claim to be using an old Microsoft or an old Adobe. devkitPro is not software but a provider of software.


    Maybe, maybe not. devkitPPC r33 should be able to compile most things that devkitPPC r29-1 did as well as some things r29-1 couldn't.

    Ultimately it would be better to update sooner rather than later and ask for help if you need it.
    For now, I rather not update to not have to ask for help. I see the problem on the other side than you explain it. maybe I don't work like I should, but as long as it works, there's no reason to update. If I do, I'll have to update all old projects I want to compile, and I prefer an error free compile than spending time updating project which are not even mine and I don't know enough to spend time fixing if I'd updated devkitpro to pacman.


    That seems like a particularly odd way to go, especially considering that it would seem like a very good opportunity to find out if your project compiles & works with latest tools. Going backwards seems rather like cleaning windows with cats and creating an awful lot of unnecessary pain.

    Anyone who wanted to compile it now for whatever reason. I don't really know why it would fail to compile with newer versions, nobody asked about it. It may be that the brief removal of big endian multilibs was why it didn't compile with some versions. In another case of cleaning windows with cats I did see a project somewhere that just dumped some random version of big endian multilibs in the middle of their build instead of asking us to reinstate the big endian support ¯\_(ツ)_/¯

    This is a very difficult thing to achieve and ultimately does more harm than good. The docker images may help up to a point but really it's going to be be better for everyone if old projects are updated and/or refactored.

    If source is available it may be possible to fix them. In some cases the last binaries may well be perfectly adequate and nobody really needs to compile them.

    Something I'm not sure people really understand is that between the tools and libraries and the pacman packages and the interdependence with many different components a devkitPro toolchain install is approaching the complexity of a small linux distro.

    I don't really care what you do within the privacy of your own hard drives, you're only hurting yourself. When you start providing old binaries and refusing to update then you're hurting everyone else too. That's when it gets problematic.

    Over the years I've seen many homebrewers give up in frustration after investing far too much time in a particular workflow or "easy" library that has turned out to be unmaintainable. It's incredibly frustrating to see people making the same mistakes over & over again despite my best efforts to maintain a solid infrastructure for homebrew code. All because doing things the right way sounds far too much like hard work and it's allegedly much more fun to clean your windows with a bloody cat.

    It's even more frustrating to see people downgrading the tools and installing conflicting software purely because someone who hasn't bothered to check how something *should* be done before writing a tutorial on how to solve a problem caused entirely by ignorance (and in some cases it's clear they haven't even followed their own tutorial since the instructions actually end up breaking the tools in some fundamental way)
     
    Last edited by realWinterMute, Dec 18, 2018
  10. leseratte
    OP

    leseratte Wiimmfi Team

    Member
    6
    Jun 2, 2012
    Germany
    I am providing devkitPro branded products which are exact copies of the original devkitPro binaries. According to the "Trademark" page in your Wiki, verbatim copies may be made by anyone, so how is this a trademark violation? Trademark violations are if someone makes a different product and tries to publish / release it as "devkitPro".

    I am obliged to provide sources for 3 years? Then how come you / the devkitPro team are not providing sources for old versions either? For example devkitPPC r28 is from November 2016, and was removed some time in 2017. Where can one get the source code for that? Or, for libogc 1.8.14 which has been released two years ago and has been available for download at least until 2017 as well?
    If I looked correctly, you are not providing that either (all the links from github have been removed) so why should I need to?

    "Providing old binaries means people don't try" - that depends on the context. If you have a homebrew developer actively developing a homebrew app, I am sure he will try to keep it updated. And even if he doesn't, he will continue using his old local copy of devkitPPC and doesn't need a mirror. Who this mirror is intended for, is for people, possibly even unexperienced people, who just want to build an old app.

    Wii IOS development, for example, still requires a fairly old devkitARM version from 2011 (as I've been told, I'm not sure if this is accurate). Updating all these to the newest version (which would be a skip of at least 15 releases) would be a huge amount of work, (even if every update on its own would only be a little work), while most of the original developers of the old cIOS aren't even in the Wii scene any more. So anyone trying to update cIOS code is basically screwed unless they get the old devkitARM from some other source.

    I agree that there are various projects that build on newer versions just fine - and I bet that if someone downloads homebrew sourcecode and wants to compile it and it works with very minor easy-to-do changes, they are going to perform those instead of figuring out the needed old version and downloading that. It is only if rewriting becomes difficult that people would even start searching for the old versions and giving up on porting to a new environment.

    And in that case, I've experienced it myself, it is most of the time done by contacting the dev (or, if needed, some other people in the homebrew scene) and get the proper old version from them to compile. If people want to get an old version, they are going to get it with the help of people who still have it. Such an archive just makes it easier.

    I don't get how this is supposed to be a problem of a mirror / of old versions in particular? Can't that happen with official binaries as well if people compile a tool and have an old version of libfat they didn't update, and a new version of libogc or other mixed versions? Of course it would be the responsibility of the user to download matching versions. But then, in most cases, you can google for which devkitPPC, libogc or other libraries versions you'd need for a given app.

    I get that, and I think that this is the goal of all software developers, improving the experience the user has with their software. However, that experience isn't going to be improved if the user is unable to use the software in its given environment. If there'd be any substancial bugs / errors causing FAT corruption or something with the most recent *working* versions of devkitPPC, don't you think the homebrew would already have been updated to work with a newer version?

    I get that using pacman and automated updates and such help getting new, improved versions out to people, and that is a good thing. But when that breaks old homebrew applications, the user experience is even better if they have an easy way to compile those anyways, with all the known bugs of the old version (which, in this case, have been present in the homebrew app all the time anyways).


    I think I did indeed understand the post.
    And I agree that *using* (not necessarily providing) old releases with no understanding is "cleaning windows with a cat".
    I also agree that asking you for help in order to fix old code is "getting a squeegee and water to clean the windows instead"

    But "grabbing old working outdated versions of devkitPPC" sometimes is the "enjoy[ing] cleaning [my] windows with a cat so much", because it is what has been done in the past and has been working in the past. And if there are users who absolutely want to do that, they should be able to do so; in my opinion.

    I agree that standardizing the toolchain and environment to compile on all systems and to allow collaborating is a great thing. But, in the case of old unmaintained homebrew, can't that be accomplished with old versions of said toolchain as well?

    I agree that it is better than before (even though I wasn't active in the GBA homebrew scene so I don't know how it was before, but from your description it definitely sounds like it was hell), and I do indeed agree that pacman is a good idea for new users to download a toolchain. I also get the idea that you got many support requests because people used broken toolchains, and redo-ing them with pacman helped. Yes, the example code will work when compiled with the pacman-version. But the old code the user cares about might not.

    Pacman is a great thing for new developers and/or newly-started projects. But, in my opinion, for old, unmaintained projects, it sometimes isn't, because even if the old toolchains might have issues and might be partially broken, they are still easier to use for said old homebrew than rewriting those for the newest toolchains.

    -------

    I hope that this helped you understand my position and why I wanted to provide said mirror. I am not trying to cause you any additional work, and I'm also not advocating the use of old toolchains for new or maintained products. But there are just edge-cases, where, in my opinion, using an old toolchain is a better solution than spending a lot of time adapting an app for the new one, even if you and the rest of the devkitPro team is willing to help with that.
     
    Brawl345 likes this.
  11. Cyan

    Cyan GBATemp's lurking knight

    Global Moderator
    22
    Oct 27, 2002
    France
    Engine room, learning
    Thank you wintermute for your answer to my concerns.
    I know I should update, I just fear to do it and find issues which I can't revert. But, I'll do it anyway as I want to allow everyone to work together on most updated version.

    Leseratte had to work on an old revision of my project because I didn't update the sources to compile on r33 yet. I'm slow and fear changes.
    I'll just have to try and see I guess.
     
    DarkDengar and baco81 like this.
  12. tswntk

    tswntk GBAtemp Advanced Fan

    Member
    6
    Aug 6, 2012
    Switzerland
    I have been wanting to modify Wiiapple to fit my need for a long long time but for the life of me, I can never compile the original project and the original developer is no where to be found. I am not well versed at coding, can you modify the source code for me to compile with the latest devkitpro? I can then work on that "fixed" source code.

    https://code.google.com/archive/p/wiiapple/downloads
     
    Last edited by tswntk, Dec 18, 2018
  13. realWinterMute

    realWinterMute GBAtemp Regular

    Member
    4
    Feb 24, 2011
    You're using the devkitPro trademarks in your url and page text without permission. You're supplying old binaries we no longer supply or support in a manner which inteferes with our ability to support our users. Please stop.


    No idea, that's why we no longer provide the binary and why you can't either.

    libogc isn't GPL and has no obligation to provide source.

    Did you try?
    .

    Nope, they run around looking for old versions instead of even trying. This is why I keep asking people not to provide old binaries and help people to update stuff instead.


    No, because the corresponding versions were updated at the same time. It's only an issue if people are updating things manually using old archives or compiling things themselves without regard for the dependencies.

    You can try but people often don't know, and if they were a victim of one of these archives of old versions then their installation may not even produce a working binary.

    You'd think, wouldn't you?

    Trouble is people don't know until it happens & some of these bugs have been pretty tricky to replicate.

    Providing old releases is exactly that though. Absurd, painful for everyone involved and unnecessarily cruel.

    You don't know which components in your archive work together and which will destroy SD cards. Neither do I, all I know is the issue was fixed with latest libfat and that various components were updated while the process of finding several bugs went on.

    As I said before, what you do in the privacy of your own hard drive is your problem.

    When you provide archives and refuse to even try updating old projects then you make it everybody else's problem too. Especially mine and I'm sick of it.
     
  14. leseratte
    OP

    leseratte Wiimmfi Team

    Member
    6
    Jun 2, 2012
    Germany
    "Trademark" is not a magical process to prevent anyone from ever saying or writing that word "devkitPro".

    You wouldn't need permission to have the word "Windows" in an URL an on a web page describing Microsoft Windows just because it is trademarked by Microsoft, would you?
    Or, for example, Android, which is open-source and trademarked. Everyone is allowed to mirror òld versions of Android and have "android" in URL, page title, and text.
    So how is "devkitPro" any different when used in the context of officially released devkitPro files (even if they are no longer available on the original page)?

    So you are not conforming with the GPL by not providing source code to the binaries you provided in the past but you are mad at me for not conforming with the GPL as well? Why should my "violation" be more serious than yours?

    No, I did not try with these specific projects, but I did try with others in the past, gave up, and used old versions, because I didn't get something to work.

    I'm afraid I don't get what you mean by that. Could you clarify?
    If there is an old homebrew, that has been compiled with (for example) devkitPPCr15, released a few years ago, and now someone wants to make one small change, downloads r15 and recompiles it. How is that going to introduce any criticial bugs that weren't there before? Any (potential) bug in r15 would have been in the old binary as well and by recompiling with the same old version no new bugs would be introduced.

    I am not refusing to try updating projects. I did try updating projects (and even succeeded on some), but for some I didn't and had to continue using old versions. And I just want people to have the freedom to do that as well if they can't get new versions to work.
     
    Sinon and ahezard like this.
  15. realWinterMute

    realWinterMute GBAtemp Regular

    Member
    4
    Feb 24, 2011

    I don't do support here, please ask on devkitPro forums @ https://devkitpro.org/viewforum.php?f=40
     
  16. realWinterMute

    realWinterMute GBAtemp Regular

    Member
    4
    Feb 24, 2011
    No, but that's not what you're doing. You're supplying devkitPro software without permission in a manner that disparages devkitPro. Please stop.

    I am no longer violating GPL by supplying a binary I can't provide source for. You're violating the GPL by supplying it, please remove your archives.

    As I said before, particular versions of devkitPPC, libogc & libfat were only ever tested together. Some combinations of those have bugs that are particularly difficult to find due to differing ABIs.

    It's impossible to say which versions are compatible with each other and the work to find out would be better aimed towards updating projects rather than playing hunt the toolchain/library combo that doesn't suffer from obscure bugs in weird circumstances.

    You're trapping people on on unsupported tools, not giving them freedom. You're interfering with our ability to support new users and you're taking away time and energy we'd rather spend improving the tools & libraries.

    If you want to work on an old project then either do it privately or update it for new tools. Stop causing support issues and remove your archives.
     
  17. dubbz82

    dubbz82 GBAtemp Advanced Maniac

    Member
    7
    Feb 2, 2014
    United States
    So reading through this, my take away is the solution for older projects that depend on versions of devkitPro is effectively to let them die?
     
  18. Coto

    Coto -

    Member
    7
    Jun 4, 2010
    Chile
    Or to port them to a new toolchain. Seeing as most code does not even belong to devkitpro.

    And then people go around asking themselves why licenses are so important. The reason is: a license will ALWAYS ensure your work belongs to you/ensures the code isn't "taken over" by someone/somebody else. Or otherwise just glue a free public domain note to your source code so if "toolchain maintainers" want to relicense their code (ie: Adding sources that do not even belong to them while adding subtle changes on top of that just to build a license), at least devs or end users can have variety of options.

    So, build a new toolchain and start adding changes from original sources and relicense that work. Or find any source code that has viral license, and build an environment with that. These would be the other options.
     
    Last edited by Coto, Dec 18, 2018
    maorninja likes this.
  19. maorninja

    maorninja GBAtemp Advanced Fan

    Member
    6
    Feb 7, 2016
    United States
    I really disagree with this.

    Sure, it's always better for new people to learn the new version and update it themselves....
    but what if people don't have programming skills and just want to compile a homebrew? I don't see any problem with that.

    Take Puffle Paddle 3DS for example. The latest DevKit can't compile it and I can't find a build anywhere. I also know it works because I remember before wiping my SD card playing it just fine.
    So now how am I supposed to play it?
     
  20. buckchow

    buckchow Member

    Newcomer
    5
    Mar 23, 2013
    United States
    That's working great for Gecko OS, right? "If we can" you say? What about when you can't do it or don't want to do it? What then? If only there was a way to get the old, original tools for quick, one-off changes to old, abandoned projects...
     
Quick Reply
Draft saved Draft deleted
Loading...