Re: GCC 4.0 Status Report (2005-02-03)
sorry for the cross-posting but this proposal will require some synergy between the three projects > * Project Title Frameworks for GNU Toolchain > * Project Contributors Matt Rice > * Dependencies Framework support in libc/bfd/binutils > * Delivery Date gcc portion is done, but blocked by the above. > * Description > What will you be doing? [GCC] Enabling the existing target framework code for darwin for other platforms, which adds a new header search mechanism for the preprocessor and passes options to ld analogous to -L and -l but with a different library search mechanism 2 new options would be added to gcc, -F and -framework -F is a combination of -I and -L which requires a specific directory structure, for example #include a simple comparison of the difference between the header search mechanism with -I/adir /adir/foo/foo.h with -F/adir /adir/foo.framework/Headers/foo.h -framework is not used by gcc other than to pass to the linker, along which -F which is also used for searching for library files, [Binutils] so when given the options "-F/adir -framework foo" ld will look for /adir/foo.framework/foo if "foo" is a symlink it will attempt to get the realpath() of the file the symlink should be inside the "foo.framework" directory or a subdirectory of it. for example "foo.framework/foo -> Versions/2/foo" this creates a versioning method so that different binaries can be linked to different versions of a framework. this will create an entry much like DT_NEEDED to "foo.framework/Versions/2/foo [1]: the ELF docs say: "If a shared object name has one or more slash (/) characters anywhere in the name, such as /usr/lib/lib2 or directory/file, the dynamic linker uses that string directly as the path name. If the name has no slashes, such as lib1, three facilities specify shared object path searching." which means it can't be used to search for a library linked relatively to a search path. making a DT_FRAMEWORK_NEEDED entry of "foo.framework/Versions/2/foo" [Glibc] will apply the to the DT_FRAMEWORK_NEEDED entry to framework search path (analogous to LD_LIBRARY_PATH etc..) looking for /adir/foo.framework/Versions/2/foo more information on frameworks available at http://developer.apple.com/documentation/MacOSX/Conceptual/BPFrameworks/index.html > What parts of the compiler will be modified? machine-specific code enabling parts of gcc/config/darwin-c.c for other platforms adding specs for new ld options > What will the benefits of your change be? (Be specific -- for > example, if you will be improving code quality, indicate what kind > of code, and, if possible, how great the improvement will be.) be able to use a relocatable self contained directory which both shared library and header files with simpler usage than lots of -I/-L or symlinks, easy cp -R installation and a shared library versioning mechanism. > What risks do you foresee? (If you say "none", you'll be asked to > resubmit...) What will you be doing to mitigate those risks? gcc: sending options to ld it doesn't understand, messing up the existing header search path. __ Do you Yahoo!? Yahoo! Mail - Easier than ever with enhanced search. Learn more. http://info.mail.yahoo.com/mail_250
Re: Updated Sourceware infrastructure plans
On Thu, Apr 18, 2024 at 5:38 PM Frank Ch. Eigler wrote: > > Hi - > > > [...] I suggest that a basic principle for such a system is that it > > should be *easy* to obtain and maintain a local copy of the history > > of all pull requests. That includes all versions of a pull request, > > if it gets rebased, and all versions of comments, if the system > > allows editing comments. A system that uses git as the source of > > truth for all the pull request data and has refs [...] > > Do you know of a system with these characteristics? > > - FChE The closest thing I know of which may have these characteristics is alibaba's AGit-Flow described here: https://git-repo.info/en/2020/03/agit-flow-and-git-repo/ It actually sends pull-requests through the git protocol using a custom proc-receive hook. I'm a bit uncertain how code-review comments are handled in their system, And it isn't exactly something which can just be used off-the-shelf, AFAIK their server side implementation hasn't been released. I had written a prototype-worthy implementation of the server-side git hook here. It basically allows sending a pull-request through git push, along with a cover letter. But i've never really used it in the full PR review cycle beyond that. https://github.com/pullreqr/pullreqr_githook But protocol-wise IMO it seems like a good basis for building a system with these characteristics to me.
Re: On pull request workflows for the GNU toolchain
On Thu, Sep 19, 2024 at 3:52 PM Joseph Myers via Gdb wrote: > > 1. Introduction > > This message expands on my remarks at the Cauldron (especially the > patch review and maintenance BoF, and the Sourceware infrastructure > BoF) regarding desired features for a system providing pull request > functionality (patch submission via creating branches that are then > proposed using some kind of web interface or API, with a central > database then tracking the status of each pull request and review > comments thereon automatically), I wasn't at Cauldron, but I just wanted to say that a lot of the web-based interfaces (git-lab, github, gitea, gogs, etc) for providing pull request functionality pre-date the existence of git-protocol features that also allow you to implement the pull request type behavior, the git proc receive hook https://git-scm.com/docs/githooks#proc-receive can be used to implement a pull-request style workflow without the web interface. This is somewhat going against the grain, and has a less developed ecosystem of clients/servers/hosting resources, I haven't kept up to date with what tools are actually available, last I looked though the only tool I knew of using it was https://git-repo.info/en/ for the client, and I written a prototype implementation using the hook as a server (as far as I know the only other server tools using this are the proprietary codeup.aliyun which might be internal to alibaba?). To me though it is nice being able to edit the PR cover letter directly in the editor, and do the pull-request using command line tools. What draws me to this however, is that it allows me to set up an in-house review process using the same set of tools that eventually feeds into upstream while mirroring the CI architecture locally. That is the dream anyway and in my opinion represents the style of pull request workflow we should be aiming for if we want something ideal. Anyhow, IMO a big reason why all of these workflows are so centralized is just that they are going outside the git protocol. To me the work that has been done seems promising as a proof of concept distributed pull request system, and what it is probably lacking is putting an actual web-based interface on top of the git protocol based design and a lot of spit and polish. At least to me the whole sourceware ecosystem feels like an ideal candidate for this, since it is much more common to have ports in progress to unfinished or unreleased instruction sets, than would happen with almost any other piece of software. So there is some amount of justification for going against the grain of a centralized system imo.
