The optmizing of directory

[NalaGinrut]

First, it's not a hurry issue.

As I mentioned in another issue, gcc front-end is unnecessarily to be part of gcc source code, we can maintain gcc/rust as a standalone project, and users may make a link to gcc/rust so that gcc can detect it automatically.

If we do so, then we don't have to consider rebase upstream code anymore.

However, if we just remove redundant parts by git rm, all the history is still kept in git database, and users will still clone the repo slowly. Not so perfect, but still better than keeping everything.

I've no idea about it, maybe we should ignore this issue at present?

[bjorn3]

However, if we just remove redundant parts by git rm, all the history is still kept in git database, and users will still clone the repo slowly. Not so perfect, but still better than keeping everything.

You can use git subtree to extract the full commit history of a single directory.

[NalaGinrut]

@bjorn3 I want to remove the unless record from git database, and keep only the record of gcc/rust

[bjorn3]

Yes, that is exactly what git subtree does. For every commit affecting a single directory, it extracts that directory from the commit and makes a new commit.

[NalaGinrut]

@bjorn3 I'm not looking for extracting, but removing the redundant part permanently.

[bjorn3]

If you force-push the extracted commit to master, that will remove the redundant part permanently.

[philberty]

Something to keep in mind is that this problem goes away if this got accepted into GCC master. Also when it comes to supporting rust libstd in a future project then we need to make change to the toplevel Makefile.tpl to include compilation for it like libgo.

I want to avoid doing any merges/rebases from GCC for time being because when we could be getting the the position of supporting the standard library we would actually be coming into a phase were we could be asking to get merged into GCC where we might get help or guidance.

I think we should keep this issue open in case more ideas come.

[philberty]

Though one option i have considered is that we keep this repo with our code only as you say but change the build.

So if this repo contains just a README and the rust front-end directory and a librust directory for the standard lib we could make scripts to wget a version of gcc tarball and merge our contents into it and perform the build and the version of gcc could be maintained with the scripts.

Its unclear if this solves anything though.

[NalaGinrut]

I think we should keep this issue open in case more ideas come.

+1

Let's just leave it open, and do other things.

[SimplyTheOther]

This is a bit late to the party, but there's also another reason why keeping gccrs inside a gcc directory structure is useful - target hooks. Essentially, the gccrs frontend requires some modifications of gcc itself to gain information about targets (e.g. pointer size, OS name, supported features like sse, avx, etc.) used in cfg attributes and elsewhere, which are known as "target hooks" in gcc parlance. This entails adding macros to gcc target headers, and hence either we'd need to keep it in the same directory as gcc, or there'd need to be some sort of complicated patching system for this (which would basically be doing the work of git manually). I bring this up because I'm working on this now - I've currently written hooks for all gcc supported OSes and some CPU architectures and just need to iron out some bugs before creating a PR for this.

[philberty]

Lets close this for now. There isn't anything we can do about this for now in the short/medium term.