Closed miigotu closed 4 years ago
@miigotu do you still need me to test building this branch?
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.
@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.
@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?
@miigotu ps3dev/gcc-PS3 created.
The submodule also serves that we don't need to get the archive and then extract it
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.
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.*
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.
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.
Btw, the commit hash for gcc-PS3
is wrong. It should be 250078
, not 84c6cf
(which does not exist)..
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
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.
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
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.
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.
Closed this, PR coming from my fork instead so I can test with proper secrets and get an image built on docker hub.
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?
Deleted it, I think that was when I was writing the submodules updater action
@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_ had to addmake install
for binutils??? Maybe you could try it out and see if it's just my environment somehow.MAKEINFO=true
to the scripts for some reason, maybe docs ignored that are added to the git repos? idk