ps3dev / ps3toolchain

A script to autobuild an open source toolchain for the PS3.
BSD 2-Clause "Simplified" License
283 stars 92 forks source link

Submodules #92

Closed miigotu closed 4 years ago

miigotu commented 4 years ago

@zeldin I need gcc-7.2.0-PS3 and gdb gdb-7.5.1-PS3 repos added here. I don't have permissions to create repos.

@bucanero @zeldin I am having an issue building with these changes now, fails make install for binutils??? Maybe you could try it out and see if it's just my environment somehow. _ had to add MAKEINFO=true to the scripts for some reason, maybe docs ignored that are added to the git repos? idk

bucanero commented 4 years ago

@miigotu do you still need me to test building this branch?

miigotu commented 4 years ago

No it builds now, I just don't quite get why it builds and fails to install docs if I don't have that makeinfo car set.

miigotu commented 4 years ago

@zeldin can you create those 2 repos?

Technically, we should just have for example "gcc-PS3" and the versions just be tagged commits, but that's for another time.

zeldin commented 4 years ago

@miigotu I'm creating a unified gcc-PS3 repo with a vendor branch, so that we can just do a merge whenever the gcc version is bumped.

As for gdb, we currently don't have any patches against upstreams, so there doesn't seem to be any benefit to making it a submodule at this time?

zeldin commented 4 years ago

@miigotu ps3dev/gcc-PS3 created.

miigotu commented 4 years ago

The submodule also serves that we don't need to get the archive and then extract it

zeldin commented 4 years ago

Either you have to get the archive and extract it, or you have to get the submodule repo and check it out. I don't see any particular benefit of doing the latter as long as there are no changes to track.

miigotu commented 4 years ago

It just makes the process uniform imo, there is probably an existing gdb repo around we can use. With current versions of git the submodules are automatically pulled when cloning, so it does save a few steps.

I also want to look into just using the submodule folder rather than copying it to the build dir, the only thing making them dirty right now is config.*

zeldin commented 4 years ago

It just makes the process uniform imo, there is probably an existing gdb repo around we can use. With current versions of git the submodules are automatically pulled when cloning, so it does save a few steps.

Well, the archive is automatically downloaded and extracted by the script, so no real difference there. Sure you could pull the upstreams repo, I just suspect it will take more time and disk space with no real benefit in return.

I also want to look into just using the submodule folder rather than copying it to the build dir, the only thing making them dirty right now is config.*

Ah, this is about config.sub and config.guess, right? (Because config.log and config.status are created in the build directory.) What we could do is remove these scripts from our own repos, and add them to .gitignore. Then copying them in does not make the working tree dirty.

zeldin commented 4 years ago

Hm, actually I have another idea: Run the newer config.guess manually (i.e. in the build script) and pass the result as --build= to configure. Then it won't run the packaged config.guess at all. It will still run the packaged config.sub, but this should be a no-op when presented with a fully qualified triplet (quadruplet) as generated by config.guess, so I think this should be an acceptable compromise.

zeldin commented 4 years ago

Btw, the commit hash for gcc-PS3 is wrong. It should be 250078, not 84c6cf (which does not exist)..

miigotu commented 4 years ago

I'll take a look at that and see if I can get that to work. Fixed the hash for the submodule, it was still the commit from my repo =P

zeldin commented 4 years ago

So I measured the time and space consumption of submodule vs downloaded archive:

Method Time Disk space
wget https://ftp.gnu.org/gnu/gdb/gdb-7.5.1.tar.bz2 ; tar xfvj gdb-7.5.1.tar.bz2 27.52 s 696M
git clone --depth 1 -b gdb_7_5-branch git://sourceware.org/git/binutils-gdb.git 32.88 s 699M

So using a submodule would take 19.5% longer time, and consume 0.4% more disk space. Probably not a big issue.

miigotu commented 4 years ago

The difference is if you delete the build dir, it has to re-download the archive. If it is a submodule the source remains. Im fine with leaving it as a wget, a uniform approach just felt nice lol

zeldin commented 4 years ago

That's easily solved by downloading to a directory that is not the build directory though. :smile: Usually you have a directory called dl or distfiles or such for this purpose.

I actually have a PR against ps3libraries which fixes exactly that, amoung other things. Maybe it's time to un-zombie it... :laughing:

But you are right that if gdb is the only package using archive download, then it becomes something of an odd duck.

miigotu commented 4 years ago

Cool. What are the triggers now? Is there a chance of getting one when savannah updates config.git?

For now, it is only triggered when a push or PR to toolchain happens (currently have it limited to submodules branch right now) Later, we will need a webhook and deploy key and there are many ways we could have that called. It could be an irc bot that watches savannah and calls the webhook when a commit is made, it could be part of the build scripts to check if it needs updated and call to the workflow, it could be a cron style job in github actions and just check daily. There are tons of ways but it will be done automagically somehow for sure, just havent decided which way yet.

miigotu commented 4 years ago

Closed this, PR coming from my fork instead so I can test with proper secrets and get an image built on docker hub.

zeldin commented 4 years ago

Nice to have many options for sure. :smile_cat: BTW, I notice that a branch 2/merge has been pushed to the repo. Is this intentional?

miigotu commented 4 years ago

Deleted it, I think that was when I was writing the submodules updater action