* Binutils 2.18 prep @ 2007-03-22 2:48 Daniel Jacobowitz 2007-03-22 10:06 ` SVN for src (was Re: Binutils 2.18 prep) Andrew STUBBS 2007-07-30 18:09 ` Binutils 2.18 prep Daniel Jacobowitz 0 siblings, 2 replies; 38+ messages in thread From: Daniel Jacobowitz @ 2007-03-22 2:48 UTC (permalink / raw) To: binutils Hello all, According to the informal schedule I've been following, binutils 2.18 should be coming up soon. I have a collection of flagged messages to go back to before I let another release out the door, but I definitely don't claim to track everything. If you have any recently committed projects (or likely to be committed soon) that should have a little more time to settle, please let me know. I expect to create the branch within a couple of weeks. I'd like to keep the branch-to-release interval fairly short; I've been using better revision control systems than CVS lately, and they've left me very bitter about having to merge patches to a CVS branch. Volunteers to find a workable way to use SVN for src instead are highly welcomed as far as I'm concerned. -- Daniel Jacobowitz CodeSourcery ^ permalink raw reply [flat|nested] 38+ messages in thread
* SVN for src (was Re: Binutils 2.18 prep) 2007-03-22 2:48 Binutils 2.18 prep Daniel Jacobowitz @ 2007-03-22 10:06 ` Andrew STUBBS 2007-03-22 10:45 ` Diego 'Flameeyes' Pettenò ` (3 more replies) 2007-07-30 18:09 ` Binutils 2.18 prep Daniel Jacobowitz 1 sibling, 4 replies; 38+ messages in thread From: Andrew STUBBS @ 2007-03-22 10:06 UTC (permalink / raw) To: binutils Daniel Jacobowitz wrote: > I expect to create the branch within a couple of weeks. I'd like to > keep the branch-to-release interval fairly short; I've been using > better revision control systems than CVS lately, and they've left me > very bitter about having to merge patches to a CVS branch. Volunteers > to find a workable way to use SVN for src instead are highly welcomed > as far as I'm concerned. My understanding is that the problem is the lack of Subversion support for something like CVS modules. I have been thinking about this problem recently. Obviously the best solution is native support from Subversion, but in it's absence I have come up with an alternative. Sorry if I've just re-invented a well known solution, but here goes: We create an Subversion directory containing all the top-level files (configure etc.), but with all the subdirectories (gas, gdb etc.) present but *empty*. We then provide a script that does 'svn switch' on each directory required for a given 'module'. This is the inverse of the svn://gcc.gnu.org/svn/gcc/emptydir idea (see http://gcc.gnu.org/wiki/SvnSetup "Optimize disk usage"). The repository might look like: trunk/ src/ configure Makefile.in ... binutils/ gas/ gdb/ ... switch-modules.sh modules/ binutils/ ar.c ... gas/ as.c ... gdb/ gdb.c ... ... So you have a two-step checkout procedure: svn checkout svn:://sourceware.org/svn/trunk/src cd src ./switch-modules.sh binutils The script would then do: svn switch svn://sourceware.org/svn/trunk/modules/binutils binutils svn switch svn://sourceware.org/svn/trunk/modules/gas gas svn switch svn://sourceware.org/svn/trunk/modules/include include ... This is not an ideal solution - it requires two steps, 'svn status' will always list all the switches, and it does not provide fine grained control over the contents of each directory. However, it does solve the problem of enormous working trees. Just a thought Andrew ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: SVN for src (was Re: Binutils 2.18 prep) 2007-03-22 10:06 ` SVN for src (was Re: Binutils 2.18 prep) Andrew STUBBS @ 2007-03-22 10:45 ` Diego 'Flameeyes' Pettenò 2007-03-22 11:06 ` Andrew STUBBS 2007-03-22 14:07 ` Paul Brook ` (2 subsequent siblings) 3 siblings, 1 reply; 38+ messages in thread From: Diego 'Flameeyes' Pettenò @ 2007-03-22 10:45 UTC (permalink / raw) To: binutils [-- Attachment #1: Type: text/plain, Size: 374 bytes --] On Thu, 22 Mar 2007 10:06:41 +0000 Andrew STUBBS <andrew.stubbs@st.com> wrote: > This is not an ideal solution - it requires two steps, 'svn status' > will always list all the switches, This should be solvable by using svn:externals [1] [1] http://svnbook.red-bean.com/en/1.1/ch07s04.html -- Diego "Flameeyes" Pettenò http://farragut.flameeyes.is-a-geek.org/ [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: SVN for src (was Re: Binutils 2.18 prep) 2007-03-22 10:45 ` Diego 'Flameeyes' Pettenò @ 2007-03-22 11:06 ` Andrew STUBBS 2007-03-22 11:23 ` Diego 'Flameeyes' Pettenò 0 siblings, 1 reply; 38+ messages in thread From: Andrew STUBBS @ 2007-03-22 11:06 UTC (permalink / raw) To: Diego 'Flameeyes' Pettenò; +Cc: binutils Diego 'Flameeyes' Pettenò wrote: > On Thu, 22 Mar 2007 10:06:41 +0000 > Andrew STUBBS <andrew.stubbs@st.com> wrote: >> This is not an ideal solution - it requires two steps, 'svn status' >> will always list all the switches, > > This should be solvable by using svn:externals [1] > > [1] http://svnbook.red-bean.com/en/1.1/ch07s04.html I think you misunderstand externals. 1. External directories are automatically checked out when you check out the parent. My suggestion is specifically NOT to check out ALL subdirectories. 2. 'svn status' lists externals, much as it does switches, so no win there. 3. You can't commit the whole tree at once, if part of it is external, unlike with switched directories (from the same repository), where it is totally transparent. Andrew ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: SVN for src (was Re: Binutils 2.18 prep) 2007-03-22 11:06 ` Andrew STUBBS @ 2007-03-22 11:23 ` Diego 'Flameeyes' Pettenò 0 siblings, 0 replies; 38+ messages in thread From: Diego 'Flameeyes' Pettenò @ 2007-03-22 11:23 UTC (permalink / raw) To: Andrew STUBBS; +Cc: binutils [-- Attachment #1: Type: text/plain, Size: 1212 bytes --] On Thu, 22 Mar 2007 11:05:57 +0000 Andrew STUBBS <andrew.stubbs@st.com> wrote: > I think you misunderstand externals. I think I rather misunderstood you, and tried to address different particular problems that you were trying to address. > 1. External directories are automatically checked out when you check > out the parent. My suggestion is specifically NOT to check out ALL > subdirectories. Okay, then for that, externals is mostly useless.. although you can still use -n to checkout non-recursively the main directory and then checkout what you actually need (this is what I actually do for KDE and a few other cases). As I said, different scopes on the suggestions, I was suggesting a way to avoid the extra script, you were suggesting a way to avoid the whole checkout. > 3. You can't commit the whole tree at once, if part of it is > external, unlike with switched directories (from the same > repository), where it is totally transparent. And this is a point well taken, I didn't think at all of this, thanks for the insight, it's something I'll have to think about next time I set up a repository. -- Diego "Flameeyes" Pettenò http://farragut.flameeyes.is-a-geek.org/ [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: SVN for src (was Re: Binutils 2.18 prep) 2007-03-22 10:06 ` SVN for src (was Re: Binutils 2.18 prep) Andrew STUBBS 2007-03-22 10:45 ` Diego 'Flameeyes' Pettenò @ 2007-03-22 14:07 ` Paul Brook 2007-03-22 14:20 ` Andrew STUBBS 2007-03-22 14:31 ` Joseph S. Myers 2007-03-22 14:11 ` Bob Rossi 2007-03-22 15:00 ` Daniel Jacobowitz 3 siblings, 2 replies; 38+ messages in thread From: Paul Brook @ 2007-03-22 14:07 UTC (permalink / raw) To: binutils; +Cc: Andrew STUBBS > We create an Subversion directory containing all the top-level files > (configure etc.), but with all the subdirectories (gas, gdb etc.) > present but *empty*. We then provide a script that does 'svn switch' on > each directory required for a given 'module'. This is the inverse of the > svn://gcc.gnu.org/svn/gcc/emptydir idea (see > http://gcc.gnu.org/wiki/SvnSetup "Optimize disk usage"). How does this work with branches and tagging? Do we have to manually (or using a script) branch+tag every subdirectory? Paul ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: SVN for src (was Re: Binutils 2.18 prep) 2007-03-22 14:07 ` Paul Brook @ 2007-03-22 14:20 ` Andrew STUBBS 2007-03-22 14:31 ` Joseph S. Myers 1 sibling, 0 replies; 38+ messages in thread From: Andrew STUBBS @ 2007-03-22 14:20 UTC (permalink / raw) To: Paul Brook; +Cc: binutils Paul Brook wrote: >> We create an Subversion directory containing all the top-level files >> (configure etc.), but with all the subdirectories (gas, gdb etc.) >> present but *empty*. We then provide a script that does 'svn switch' on >> each directory required for a given 'module'. This is the inverse of the >> svn://gcc.gnu.org/svn/gcc/emptydir idea (see >> http://gcc.gnu.org/wiki/SvnSetup "Optimize disk usage"). > > How does this work with branches and tagging? Do we have to manually (or using > a script) branch+tag every subdirectory? If you branch/tag the whole trunk then there's no problem. E.g. tags/ 2.18/ src/ modules/ trunk/ src/ modules/ Of course, the script to do the switching has to be able to detect what branch to use. However, the most portable approach would be to look for the modules relative to the URL obtained using 'svn info'. That would work even when the URL changes or the repository is mirrored. Andrew ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: SVN for src (was Re: Binutils 2.18 prep) 2007-03-22 14:07 ` Paul Brook 2007-03-22 14:20 ` Andrew STUBBS @ 2007-03-22 14:31 ` Joseph S. Myers 1 sibling, 0 replies; 38+ messages in thread From: Joseph S. Myers @ 2007-03-22 14:31 UTC (permalink / raw) To: Paul Brook; +Cc: binutils, Andrew STUBBS On Thu, 22 Mar 2007, Paul Brook wrote: > > We create an Subversion directory containing all the top-level files > > (configure etc.), but with all the subdirectories (gas, gdb etc.) > > present but *empty*. We then provide a script that does 'svn switch' on > > each directory required for a given 'module'. This is the inverse of the > > svn://gcc.gnu.org/svn/gcc/emptydir idea (see > > http://gcc.gnu.org/wiki/SvnSetup "Optimize disk usage"). > > How does this work with branches and tagging? Do we have to manually (or using > a script) branch+tag every subdirectory? You can copy a checkout to a URI. I know that works for modified and mixed-revision working copies; if it works for switched working copies, you'd get a branch or tag replicating that copy (so with binutils only if it was a checkout switched to be a binutils-only checkout, for example). -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: SVN for src (was Re: Binutils 2.18 prep) 2007-03-22 10:06 ` SVN for src (was Re: Binutils 2.18 prep) Andrew STUBBS 2007-03-22 10:45 ` Diego 'Flameeyes' Pettenò 2007-03-22 14:07 ` Paul Brook @ 2007-03-22 14:11 ` Bob Rossi 2007-03-22 14:17 ` Daniel Jacobowitz 2007-03-22 15:00 ` Daniel Jacobowitz 3 siblings, 1 reply; 38+ messages in thread From: Bob Rossi @ 2007-03-22 14:11 UTC (permalink / raw) To: Andrew STUBBS; +Cc: binutils On Thu, Mar 22, 2007 at 10:06:41AM +0000, Andrew STUBBS wrote: > Daniel Jacobowitz wrote: > >I expect to create the branch within a couple of weeks. I'd like to > >keep the branch-to-release interval fairly short; I've been using > >better revision control systems than CVS lately, and they've left me > >very bitter about having to merge patches to a CVS branch. Volunteers > >to find a workable way to use SVN for src instead are highly welcomed > >as far as I'm concerned. > > My understanding is that the problem is the lack of Subversion support > for something like CVS modules. It seems to me like a high profile project like this might be able to get the subversion guys to add a feature or two in order to make svn more usable in large, real world projects? Bob Rossi ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: SVN for src (was Re: Binutils 2.18 prep) 2007-03-22 14:11 ` Bob Rossi @ 2007-03-22 14:17 ` Daniel Jacobowitz 0 siblings, 0 replies; 38+ messages in thread From: Daniel Jacobowitz @ 2007-03-22 14:17 UTC (permalink / raw) To: Andrew STUBBS, binutils; +Cc: dberlin On Thu, Mar 22, 2007 at 10:11:22AM -0400, Bob Rossi wrote: > On Thu, Mar 22, 2007 at 10:06:41AM +0000, Andrew STUBBS wrote: > > Daniel Jacobowitz wrote: > > >I expect to create the branch within a couple of weeks. I'd like to > > >keep the branch-to-release interval fairly short; I've been using > > >better revision control systems than CVS lately, and they've left me > > >very bitter about having to merge patches to a CVS branch. Volunteers > > >to find a workable way to use SVN for src instead are highly welcomed > > >as far as I'm concerned. > > > > My understanding is that the problem is the lack of Subversion support > > for something like CVS modules. > > It seems to me like a high profile project like this might be able to > get the subversion guys to add a feature or two in order to make svn > more usable in large, real world projects? I think the feature we need is even on the drawing board already for an unspecified future release - an equivalent to svk's "views". Dan, am I just making that up? -- Daniel Jacobowitz CodeSourcery ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: SVN for src (was Re: Binutils 2.18 prep) 2007-03-22 10:06 ` SVN for src (was Re: Binutils 2.18 prep) Andrew STUBBS ` (2 preceding siblings ...) 2007-03-22 14:11 ` Bob Rossi @ 2007-03-22 15:00 ` Daniel Jacobowitz 2007-03-22 15:28 ` Daniel Jacobowitz ` (2 more replies) 3 siblings, 3 replies; 38+ messages in thread From: Daniel Jacobowitz @ 2007-03-22 15:00 UTC (permalink / raw) To: binutils On Thu, Mar 22, 2007 at 10:06:41AM +0000, Andrew STUBBS wrote: > We create an Subversion directory containing all the top-level files (configure > etc.), but with all the subdirectories (gas, gdb etc.) present but *empty*. We > then provide a script that does 'svn switch' on each directory required for a > given 'module'. This is the inverse of the svn://gcc.gnu.org/svn/gcc/emptydir > idea (see http://gcc.gnu.org/wiki/SvnSetup "Optimize disk usage"). You know, I think we can do this even without having to butcher the layout of the repository. Check out a directory containing just the script, and have it use "svn switch -N" at the end to pick up the top level files. I'm going to experiment. I have a handy repository to work with :-) (We import CVS snapshots into svn.) -- Daniel Jacobowitz CodeSourcery ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: SVN for src (was Re: Binutils 2.18 prep) 2007-03-22 15:00 ` Daniel Jacobowitz @ 2007-03-22 15:28 ` Daniel Jacobowitz 2007-03-22 15:51 ` Andrew STUBBS 2007-03-22 15:35 ` Andrew STUBBS 2007-03-22 16:48 ` DJ Delorie 2 siblings, 1 reply; 38+ messages in thread From: Daniel Jacobowitz @ 2007-03-22 15:28 UTC (permalink / raw) To: binutils On Thu, Mar 22, 2007 at 11:00:18AM -0400, Daniel Jacobowitz wrote: > On Thu, Mar 22, 2007 at 10:06:41AM +0000, Andrew STUBBS wrote: > > We create an Subversion directory containing all the top-level files (configure > > etc.), but with all the subdirectories (gas, gdb etc.) present but *empty*. We > > then provide a script that does 'svn switch' on each directory required for a > > given 'module'. This is the inverse of the svn://gcc.gnu.org/svn/gcc/emptydir > > idea (see http://gcc.gnu.org/wiki/SvnSetup "Optimize disk usage"). > > You know, I think we can do this even without having to butcher the > layout of the repository. Check out a directory containing just the > script, and have it use "svn switch -N" at the end to pick up the top > level files. > > I'm going to experiment. I have a handy repository to work with :-) > (We import CVS snapshots into svn.) Here's what I've got so far. These are all just my observations, so my assertions about how Subversion works may be bogus. Suppose we leave the repository layout exactly the same as it is now. Check out the trunk using "svn co -N" for non-recursive. You will get only the trunk - no subdirectories. Unlike in CVS they will never spontaneously appear after this point; "svn up" will only create new directories when it updates through a revision in the repository that created the directory. Otherwise, it appears to assume that the directory is deliberately missing if it is not mentioned in .svn/entries. However, an explicit "svn up gdb" in this case will work! So, we can put a script in the top level to check out a module. If you check out the repository URL you'll get all of src; if you check out using -N and run the script with appropriate argument, you'll get only binutils. Or only GDB, et cetera. We'll probably need to maintain a list of subdirectories for anything where directories are omitted from some modules; that's top level, gdb and gdb/testsuite/ (for Insight), and cgen. It'll be a hassle but not a huge hassle. Not everything is rosy. "svn cp . $repo/branches/new-branch" will copy the omitted directories, which is peculiar, so we would either need people branching to get a hypothetical svn which didn't do that or use a script to create branches. But it's much less messy than using externals would be. Any thoughts? Is this really workable? -- Daniel Jacobowitz CodeSourcery ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: SVN for src (was Re: Binutils 2.18 prep) 2007-03-22 15:28 ` Daniel Jacobowitz @ 2007-03-22 15:51 ` Andrew STUBBS 2007-03-26 14:59 ` Daniel Jacobowitz 0 siblings, 1 reply; 38+ messages in thread From: Andrew STUBBS @ 2007-03-22 15:51 UTC (permalink / raw) To: binutils Daniel Jacobowitz wrote: > Check out the trunk using "svn co -N" for non-recursive. You will get > only the trunk - no subdirectories. Unlike in CVS they will never > spontaneously appear after this point; "svn up" will only create new > directories when it updates through a revision in the repository that > created the directory. Otherwise, it appears to assume that the > directory is deliberately missing if it is not mentioned in > .svn/entries. However, an explicit "svn up gdb" in this case will > work! Try a commit. I'm fairly sure that any subsequent check-outs within the working-copy are separate - you can't check-in changes to different directories simultaneously. It will be perfectly adequate for building and diffing, of course. > Not everything is rosy. "svn cp . $repo/branches/new-branch" will > copy the omitted directories, which is peculiar, so we would either > need people branching to get a hypothetical svn which didn't do that > or use a script to create branches. But it's much less messy than > using externals would be. What's wrong with creating a branch that contains everything? This is the natural way to work with svn - copies are not expensive. One can then check out modules on the branch in the same way as the trunk. This does raise an interesting point: it would not be trivial to 'svn switch' to different branches. Not impossible, but not trivial. Andrew ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: SVN for src (was Re: Binutils 2.18 prep) 2007-03-22 15:51 ` Andrew STUBBS @ 2007-03-26 14:59 ` Daniel Jacobowitz 2007-03-26 16:32 ` Andrew STUBBS 0 siblings, 1 reply; 38+ messages in thread From: Daniel Jacobowitz @ 2007-03-26 14:59 UTC (permalink / raw) To: Andrew STUBBS; +Cc: binutils On Thu, Mar 22, 2007 at 03:51:45PM +0000, Andrew STUBBS wrote: > Daniel Jacobowitz wrote: > >Check out the trunk using "svn co -N" for non-recursive. You will get > >only the trunk - no subdirectories. Unlike in CVS they will never > >spontaneously appear after this point; "svn up" will only create new > >directories when it updates through a revision in the repository that > >created the directory. Otherwise, it appears to assume that the > >directory is deliberately missing if it is not mentioned in > >.svn/entries. However, an explicit "svn up gdb" in this case will > >work! > Try a commit. I'm fairly sure that any subsequent check-outs within the > working-copy are separate - you can't check-in changes to different directories > simultaneously. > It will be perfectly adequate for building and diffing, of course. "svn co" in a checkout creates something completely separate; "svn up" as I described does not. So commiting worked. But checking out libiberty and libiberty/config, then committing to libiberty testsuite from another tree, then svn updating the first tree failed with 'Directory "testsuite" is missing'. A second svn up pulled in the directory. I guess that means it's not going to work out this way. Drat. -- Daniel Jacobowitz CodeSourcery ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: SVN for src (was Re: Binutils 2.18 prep) 2007-03-26 14:59 ` Daniel Jacobowitz @ 2007-03-26 16:32 ` Andrew STUBBS 2007-04-10 17:25 ` Daniel Jacobowitz 0 siblings, 1 reply; 38+ messages in thread From: Andrew STUBBS @ 2007-03-26 16:32 UTC (permalink / raw) To: binutils Daniel Jacobowitz wrote: > "svn co" in a checkout creates something completely separate; "svn up" > as I described does not. So commiting worked. But checking out > libiberty and libiberty/config, then committing to libiberty testsuite > from another tree, then svn updating the first tree failed with > 'Directory "testsuite" is missing'. A second svn up pulled in the > directory. > > I guess that means it's not going to work out this way. Drat. I thought I tested "svn up <dir>" and it didn't work??? Maybe it's an svn version thing, or maybe my memory is broken. Anyway, when I try it now it does work, and I have reproduced your issue. That gives 3 issues with this approach: 1. "svn up -r" 2. "svn switch" 3. "svn up" when something has changed in a "missing" directory. I have done a few experiments, and I believe this can all be fixed with the same set of -N options that were used in the initial "checkout". E.g. If you checkout with: svn co svn:...src -N svn up src/libiberty -N svn up src/config then you must update with: svn up src -N svn up src/libiberty -N svn up src/config and switch to branch/update to revision with: svn up -r$rev src -N svn up -r$rev src/libiberty -N svn up -r$rev src/config I think the script to do the checkout can be used for all these tasks and can remove all these issues. That is, provided that the user never does anything else 'creative'. If the user does their own updates/switches then the script might to something undesirable. There is also one other *big* issue, although it may not seem like it for CVS users. Any directory checked out or updated with -N will cause newly created subdirectories to be omitted from checkouts, or conversely, newly deleted directories will be left in (and these effects will be reversed when the current revision is moved backwards). A simple solution to this problem would be to limit module selection to top-level directories only (and then do a full recursive update for each). A more complex solution would be to have the script recurse over the whole tree and "deal" with each directory (note that "svn ls" always lists directories that are "missing"). The script would have to either update itself first, in order to make sure the set of directories is correct, or else the module information would have to be encoded as svn properties on each directory, and thus automatically updated. All in all, I believe that, even before subversion introduces proper support for something module-like, it is possible to switch to subversion, provided that users are prepared to be disciplined in their use of checkout and update. There will be no need to modify the structure of the repository (so people who checkout the whole world still can), and when svn modules are implemented, there will be no painful transition (of our doing). Andrew ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: SVN for src (was Re: Binutils 2.18 prep) 2007-03-26 16:32 ` Andrew STUBBS @ 2007-04-10 17:25 ` Daniel Jacobowitz 2007-04-11 10:22 ` Andrew STUBBS 0 siblings, 1 reply; 38+ messages in thread From: Daniel Jacobowitz @ 2007-04-10 17:25 UTC (permalink / raw) To: binutils On Mon, Mar 26, 2007 at 05:16:17PM +0100, Andrew STUBBS wrote: > All in all, I believe that, even before subversion introduces proper support > for something module-like, it is possible to switch to subversion, provided > that users are prepared to be disciplined in their use of checkout and update. > There will be no need to modify the structure of the repository (so people who > checkout the whole world still can), and when svn modules are implemented, > there will be no painful transition (of our doing). Anyway, let's wait. Jim Blandy pointed out to me that most of what we need will be in Subversion 1.5 ("sparse directories"). It may be awkward, especially for gdb/testsuite/gdb.gdbtk, but we'll work something out. -- Daniel Jacobowitz CodeSourcery ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: SVN for src (was Re: Binutils 2.18 prep) 2007-04-10 17:25 ` Daniel Jacobowitz @ 2007-04-11 10:22 ` Andrew STUBBS 2007-04-11 11:06 ` Daniel Jacobowitz 2007-04-11 14:18 ` Ian Lance Taylor 0 siblings, 2 replies; 38+ messages in thread From: Andrew STUBBS @ 2007-04-11 10:22 UTC (permalink / raw) To: binutils Daniel Jacobowitz wrote: > On Mon, Mar 26, 2007 at 05:16:17PM +0100, Andrew STUBBS wrote: >> All in all, I believe that, even before subversion introduces proper support >> for something module-like, it is possible to switch to subversion, provided >> that users are prepared to be disciplined in their use of checkout and update. >> There will be no need to modify the structure of the repository (so people who >> checkout the whole world still can), and when svn modules are implemented, >> there will be no painful transition (of our doing). > > Anyway, let's wait. Jim Blandy pointed out to me that most of what we > need will be in Subversion 1.5 ("sparse directories"). It may be > awkward, especially for gdb/testsuite/gdb.gdbtk, but we'll work > something out. I had not heard of sparse directories, but then I don't follow SVN development. I'm not sure where the proper documentation of these features might be, but I found this: http://svn.collab.net/viewvc/svn/trunk/notes/sparse-directories.txt?view=markup It would appear that the new feature is exactly what we were discussing, except with the update/switch issues resolved. We would still need a checkout script to implement the `modules', but it would not be necessary to use it for switch or update. Indeed it would also appear to be no more powerful than the accidental-feature abuse we were talking about - i.e. you can choose your directories, but you can't choose your files. I do not see a big issue with gdb.gdbtk, or indeed the various bits of include that are not distributed with some projects. Care would have to be taken that updates don't ignore new directories, but that's just a question of ensuring that each directory has the proper depth parameter set. I would suggest now that the real problem is how to convert CVS to SVN. I haven't even got a clue how that could be done. The GCC project managed it, but I imagine that it will take a CVS expert some time to get that mammoth process completed. Andrew ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: SVN for src (was Re: Binutils 2.18 prep) 2007-04-11 10:22 ` Andrew STUBBS @ 2007-04-11 11:06 ` Daniel Jacobowitz 2007-04-11 13:46 ` Paul Koning 2007-04-11 14:18 ` Ian Lance Taylor 1 sibling, 1 reply; 38+ messages in thread From: Daniel Jacobowitz @ 2007-04-11 11:06 UTC (permalink / raw) To: binutils On Wed, Apr 11, 2007 at 11:22:23AM +0100, Andrew STUBBS wrote: > I would suggest now that the real problem is how to convert CVS to SVN. I > haven't even got a clue how that could be done. The GCC project managed it, but > I imagine that it will take a CVS expert some time to get that mammoth process > completed. Actually, that part is quite simple. cvs2svn is a very good utility :-) -- Daniel Jacobowitz CodeSourcery ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: SVN for src (was Re: Binutils 2.18 prep) 2007-04-11 11:06 ` Daniel Jacobowitz @ 2007-04-11 13:46 ` Paul Koning 0 siblings, 0 replies; 38+ messages in thread From: Paul Koning @ 2007-04-11 13:46 UTC (permalink / raw) To: drow; +Cc: binutils >>>>> "Daniel" == Daniel Jacobowitz <drow@false.org> writes: Daniel> On Wed, Apr 11, 2007 at 11:22:23AM +0100, Andrew STUBBS Daniel> wrote: >> I would suggest now that the real problem is how to convert CVS to >> SVN. I haven't even got a clue how that could be done. The GCC >> project managed it, but I imagine that it will take a CVS expert >> some time to get that mammoth process completed. Daniel> Actually, that part is quite simple. cvs2svn is a very good Daniel> utility :-) Absolutely. I used it a bit over a year ago on a large project, and of course the GCC project did likewise. It was entirely painless. Just run it and admire the result. paul ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: SVN for src (was Re: Binutils 2.18 prep) 2007-04-11 10:22 ` Andrew STUBBS 2007-04-11 11:06 ` Daniel Jacobowitz @ 2007-04-11 14:18 ` Ian Lance Taylor 2007-04-11 15:00 ` Daniel Jacobowitz 1 sibling, 1 reply; 38+ messages in thread From: Ian Lance Taylor @ 2007-04-11 14:18 UTC (permalink / raw) To: Andrew STUBBS, nickc; +Cc: binutils Andrew STUBBS <andrew.stubbs@st.com> writes: > I would suggest now that the real problem is how to convert CVS to > SVN. I haven't even got a clue how that could be done. The GCC project > managed it, but I imagine that it will take a CVS expert some time to > get that mammoth process completed. The gcc conversion, which was done by Daniel Berlin, had two interesting parts. The first was that the gcc repository was very large with a lot of revisions, and the conversion process took more than two days on a powerful system. The second was that we wanted to include older gcc version data from the FSF RCS files which were not in the CVS repository. I wrote some hacks to include the RCS revision history in a copy of the CVS repository before the revision. I would very much like to do the same thing with the old Cygnus binutils repository at Red Hat. The problem is the customer confidential code in the Cygnus repository. However, we would only be interested in the Cygnus repository up to the point when the sourceware repository was created, in May 1999. When I was at Cygnus we always wrote our contracts to say that confidential information could be released when the customer specified or after three years had passed. So, unless they changed that policy after I left in 1998, an eight year lag should be legally OK. Nick, could you see if you can get permission to release the binutils/gdb/newlib/cygwin revision history from the Cygnus repository up through May, 1999? If you can, I'll work on incorporating that revision history into the sourceware repository. I think that would be very convenient for future development. Ian ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: SVN for src (was Re: Binutils 2.18 prep) 2007-04-11 14:18 ` Ian Lance Taylor @ 2007-04-11 15:00 ` Daniel Jacobowitz 2007-04-11 15:23 ` Ian Lance Taylor 0 siblings, 1 reply; 38+ messages in thread From: Daniel Jacobowitz @ 2007-04-11 15:00 UTC (permalink / raw) To: binutils On Wed, Apr 11, 2007 at 07:14:34AM -0700, Ian Lance Taylor wrote: > Nick, could you see if you can get permission to release the > binutils/gdb/newlib/cygwin revision history from the Cygnus repository > up through May, 1999? If you can, I'll work on incorporating that > revision history into the sourceware repository. > > I think that would be very convenient for future development. This hadn't even occurred to me - but it would be great to have! The result might be a bit confusing; I believe the gcc.gnu.org repository just began when it began, but the sourceware repository had snapshots of previous GDB releases imported into it. So things may seem to appear and then disappear. -- Daniel Jacobowitz CodeSourcery ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: SVN for src (was Re: Binutils 2.18 prep) 2007-04-11 15:00 ` Daniel Jacobowitz @ 2007-04-11 15:23 ` Ian Lance Taylor 0 siblings, 0 replies; 38+ messages in thread From: Ian Lance Taylor @ 2007-04-11 15:23 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: binutils Daniel Jacobowitz <drow@false.org> writes: > On Wed, Apr 11, 2007 at 07:14:34AM -0700, Ian Lance Taylor wrote: > > Nick, could you see if you can get permission to release the > > binutils/gdb/newlib/cygwin revision history from the Cygnus repository > > up through May, 1999? If you can, I'll work on incorporating that > > revision history into the sourceware repository. > > > > I think that would be very convenient for future development. > > This hadn't even occurred to me - but it would be great to have! > The result might be a bit confusing; I believe the gcc.gnu.org > repository just began when it began, but the sourceware repository had > snapshots of previous GDB releases imported into it. So things may > seem to appear and then disappear. We control the horizontal and the vertical. If we get the old binutils/gdb revision history, we can clobber the gdb snapshots when we merge. Ian ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: SVN for src (was Re: Binutils 2.18 prep) 2007-03-22 15:00 ` Daniel Jacobowitz 2007-03-22 15:28 ` Daniel Jacobowitz @ 2007-03-22 15:35 ` Andrew STUBBS 2007-03-22 16:48 ` DJ Delorie 2 siblings, 0 replies; 38+ messages in thread From: Andrew STUBBS @ 2007-03-22 15:35 UTC (permalink / raw) To: binutils Daniel Jacobowitz wrote: > On Thu, Mar 22, 2007 at 10:06:41AM +0000, Andrew STUBBS wrote: >> We create an Subversion directory containing all the top-level files (configure >> etc.), but with all the subdirectories (gas, gdb etc.) present but *empty*. We >> then provide a script that does 'svn switch' on each directory required for a >> given 'module'. This is the inverse of the svn://gcc.gnu.org/svn/gcc/emptydir >> idea (see http://gcc.gnu.org/wiki/SvnSetup "Optimize disk usage"). > > You know, I think we can do this even without having to butcher the > layout of the repository. Check out a directory containing just the > script, and have it use "svn switch -N" at the end to pick up the top > level files. > > I'm going to experiment. I have a handy repository to work with :-) > (We import CVS snapshots into svn.) Magic, it works! I did originally think about doing 'svn co -N src', but that makes it impossible to get at the subdirectories at all (another checkout works, but then you can't check in properly). I hadn't though of pulling in the root via switch. Nice idea. So we would have: svn co svn://sourceware.org/svn/trunk/modular-checkout src cd src ./checkout binutils which would then do: svn switch svn://sourceware.org/svn/trunk/src/binutils binutils svn switch svn://sourceware.org/svn/trunk/src/gas gas ... svn switch -N svn://sourceware.org/svn/trunk/src . where the last line switches in the top level files, and switches out the checkout script itself. Anybody wanting to checkout *everything* still can, without jumping through hoops! I suppose that, given the -N switch, it is even possible to selectively choose subdirectories (such as include/elf), as long as the empty version already exists, thus: svn switch -N svn://sourceware.org/svn/trunk/src/include include svn switch svn://sourceware.org/svn/trunk/src/include/elf \ include/elf I can't think of any way to select individual files. Andrew ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: SVN for src (was Re: Binutils 2.18 prep) 2007-03-22 15:00 ` Daniel Jacobowitz 2007-03-22 15:28 ` Daniel Jacobowitz 2007-03-22 15:35 ` Andrew STUBBS @ 2007-03-22 16:48 ` DJ Delorie 2007-03-22 17:08 ` Andrew STUBBS 2007-03-26 14:57 ` Daniel Jacobowitz 2 siblings, 2 replies; 38+ messages in thread From: DJ Delorie @ 2007-03-22 16:48 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: binutils Daniel Jacobowitz <drow@false.org> writes: > You know, I think we can do this even without having to butcher the > layout of the repository. Check out a directory containing just the > script, and have it use "svn switch -N" at the end to pick up the top > level files. The thing to watch out for is an svn update to a different revision, which has a tendency to re-populate all the missing directories. I've gotten bitten by this a few times trying to track down gcc bugs by date; it kept pulling in the ada/java sources and I kept trying to delete them. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: SVN for src (was Re: Binutils 2.18 prep) 2007-03-22 16:48 ` DJ Delorie @ 2007-03-22 17:08 ` Andrew STUBBS 2007-03-22 18:15 ` DJ Delorie 2007-03-26 14:57 ` Daniel Jacobowitz 1 sibling, 1 reply; 38+ messages in thread From: Andrew STUBBS @ 2007-03-22 17:08 UTC (permalink / raw) To: DJ Delorie; +Cc: Daniel Jacobowitz, binutils DJ Delorie wrote: > Daniel Jacobowitz <drow@false.org> writes: >> You know, I think we can do this even without having to butcher the >> layout of the repository. Check out a directory containing just the >> script, and have it use "svn switch -N" at the end to pick up the top >> level files. > > The thing to watch out for is an svn update to a different revision, > which has a tendency to re-populate all the missing directories. I've > gotten bitten by this a few times trying to track down gcc bugs by > date; it kept pulling in the ada/java sources and I kept trying to > delete them. > Even when you followed the "optimize disk usage" instructions at http://gcc.gnu.org/wiki/SvnSetup ??? Andrew ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: SVN for src (was Re: Binutils 2.18 prep) 2007-03-22 17:08 ` Andrew STUBBS @ 2007-03-22 18:15 ` DJ Delorie 2007-03-23 9:12 ` Andrew STUBBS 0 siblings, 1 reply; 38+ messages in thread From: DJ Delorie @ 2007-03-22 18:15 UTC (permalink / raw) To: andrew.stubbs; +Cc: drow, binutils > Even when you followed the "optimize disk usage" instructions at > http://gcc.gnu.org/wiki/SvnSetup ??? Yes. Updating to a specific date seems to undo the svn switch. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: SVN for src (was Re: Binutils 2.18 prep) 2007-03-22 18:15 ` DJ Delorie @ 2007-03-23 9:12 ` Andrew STUBBS 0 siblings, 0 replies; 38+ messages in thread From: Andrew STUBBS @ 2007-03-23 9:12 UTC (permalink / raw) To: DJ Delorie; +Cc: drow, binutils DJ Delorie wrote: >> Even when you followed the "optimize disk usage" instructions at >> http://gcc.gnu.org/wiki/SvnSetup ??? > > Yes. Updating to a specific date seems to undo the svn switch. But a regular update (to head) works as expected? Inconvenient. The manual does suggest that update is just a special case of switch. I guess updating to a specific date isn't so special - it's exactly switch to the date. I suppose someone needs to report that one to the SVN guys, if they don't already know. Andrew ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: SVN for src (was Re: Binutils 2.18 prep) 2007-03-22 16:48 ` DJ Delorie 2007-03-22 17:08 ` Andrew STUBBS @ 2007-03-26 14:57 ` Daniel Jacobowitz 2007-03-26 15:16 ` Daniel Jacobowitz 1 sibling, 1 reply; 38+ messages in thread From: Daniel Jacobowitz @ 2007-03-26 14:57 UTC (permalink / raw) To: DJ Delorie; +Cc: binutils On Thu, Mar 22, 2007 at 12:11:15PM -0400, DJ Delorie wrote: > Daniel Jacobowitz <drow@false.org> writes: > > You know, I think we can do this even without having to butcher the > > layout of the repository. Check out a directory containing just the > > script, and have it use "svn switch -N" at the end to pick up the top > > level files. > > The thing to watch out for is an svn update to a different revision, > which has a tendency to re-populate all the missing directories. I've > gotten bitten by this a few times trying to track down gcc bugs by > date; it kept pulling in the ada/java sources and I kept trying to > delete them. Can you be more specific? I tried to reproduce this, to find problems with my tentative plan, but I couldn't. It might be disrupted if you use -r before and after the creation of a directory, but I think only for that directory. -- Daniel Jacobowitz CodeSourcery ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: SVN for src (was Re: Binutils 2.18 prep) 2007-03-26 14:57 ` Daniel Jacobowitz @ 2007-03-26 15:16 ` Daniel Jacobowitz 0 siblings, 0 replies; 38+ messages in thread From: Daniel Jacobowitz @ 2007-03-26 15:16 UTC (permalink / raw) To: DJ Delorie, binutils On Mon, Mar 26, 2007 at 10:45:14AM -0400, Daniel Jacobowitz wrote: > On Thu, Mar 22, 2007 at 12:11:15PM -0400, DJ Delorie wrote: > > Daniel Jacobowitz <drow@false.org> writes: > > > You know, I think we can do this even without having to butcher the > > > layout of the repository. Check out a directory containing just the > > > script, and have it use "svn switch -N" at the end to pick up the top > > > level files. > > > > The thing to watch out for is an svn update to a different revision, > > which has a tendency to re-populate all the missing directories. I've > > gotten bitten by this a few times trying to track down gcc bugs by > > date; it kept pulling in the ada/java sources and I kept trying to > > delete them. > > Can you be more specific? I tried to reproduce this, to find problems > with my tentative plan, but I couldn't. It might be disrupted if you > use -r before and after the creation of a directory, but I think only > for that directory. Never mind. I see now. % svn switch file:///space/codesourcery/local-svk/local/empty testsuite % svn up % svn up -r330 D testsuite ... svn: Directory 'testsuite' is missing % svn up -r330 A testsuite A testsuite/test-pexecute.c ... Whoops. -- Daniel Jacobowitz CodeSourcery ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Binutils 2.18 prep 2007-03-22 2:48 Binutils 2.18 prep Daniel Jacobowitz 2007-03-22 10:06 ` SVN for src (was Re: Binutils 2.18 prep) Andrew STUBBS @ 2007-07-30 18:09 ` Daniel Jacobowitz 2007-07-30 18:14 ` H.J. Lu ` (2 more replies) 1 sibling, 3 replies; 38+ messages in thread From: Daniel Jacobowitz @ 2007-07-30 18:09 UTC (permalink / raw) To: binutils On Wed, Mar 21, 2007 at 10:48:38PM -0400, Daniel Jacobowitz wrote: > Hello all, > > According to the informal schedule I've been following, binutils 2.18 > should be coming up soon. I have a collection of flagged messages to > go back to before I let another release out the door, but I definitely > don't claim to track everything. If you have any recently committed > projects (or likely to be committed soon) that should have a little > more time to settle, please let me know. Hi folks, Obviously that didn't happen. Let's try again. If you know of any issues in HEAD that should not be in a stable release, please let me know. Otherwise, I will tentatively plan: - Branch 6th August - Release 27th August -- Daniel Jacobowitz CodeSourcery ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Binutils 2.18 prep 2007-07-30 18:09 ` Binutils 2.18 prep Daniel Jacobowitz @ 2007-07-30 18:14 ` H.J. Lu 2007-08-01 17:57 ` Jim Wilson 2007-08-06 21:13 ` Daniel Jacobowitz 2 siblings, 0 replies; 38+ messages in thread From: H.J. Lu @ 2007-07-30 18:14 UTC (permalink / raw) To: binutils On Mon, Jul 30, 2007 at 12:51:46PM -0400, Daniel Jacobowitz wrote: > On Wed, Mar 21, 2007 at 10:48:38PM -0400, Daniel Jacobowitz wrote: > > Hello all, > > > > According to the informal schedule I've been following, binutils 2.18 > > should be coming up soon. I have a collection of flagged messages to > > go back to before I let another release out the door, but I definitely > > don't claim to track everything. If you have any recently committed > > projects (or likely to be committed soon) that should have a little > > more time to settle, please let me know. > > Hi folks, > > Obviously that didn't happen. Let's try again. If you know of any > issues in HEAD that should not be in a stable release, please let me > know. Otherwise, I will tentatively plan: > We need to resolve: http://sources.redhat.com/bugzilla/show_bug.cgi?id=4781 H.J. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Binutils 2.18 prep 2007-07-30 18:09 ` Binutils 2.18 prep Daniel Jacobowitz 2007-07-30 18:14 ` H.J. Lu @ 2007-08-01 17:57 ` Jim Wilson 2007-08-02 0:08 ` l l 2007-08-06 21:13 ` Daniel Jacobowitz 2 siblings, 1 reply; 38+ messages in thread From: Jim Wilson @ 2007-08-01 17:57 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: binutils On Mon, 2007-07-30 at 12:51 -0400, Daniel Jacobowitz wrote: > Obviously that didn't happen. Let's try again. If you know of any > issues in HEAD that should not be in a stable release, please let me > know. Otherwise, I will tentatively plan: I've been a bit negligent with my IA-64 maintainership duties. I have some patches I need to review. I'm not sure if there is anything critical in there though. But I've got a month to get this straightened out, so this should be no reason to delay the branch. -- Jim Wilson, GNU Tools Support, http://www.specifix.com ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Binutils 2.18 prep 2007-08-01 17:57 ` Jim Wilson @ 2007-08-02 0:08 ` l l 0 siblings, 0 replies; 38+ messages in thread From: l l @ 2007-08-02 0:08 UTC (permalink / raw) To: Jim Wilson; +Cc: Daniel Jacobowitz, binutils Hi, I wish more support for x86_64. I am using amd64 x2 4800+ 65nm. TIA 2007/8/2, Jim Wilson <wilson@specifix.com>: > On Mon, 2007-07-30 at 12:51 -0400, Daniel Jacobowitz wrote: > > Obviously that didn't happen. Let's try again. If you know of any > > issues in HEAD that should not be in a stable release, please let me > > know. Otherwise, I will tentatively plan: > > I've been a bit negligent with my IA-64 maintainership duties. I have > some patches I need to review. I'm not sure if there is anything > critical in there though. But I've got a month to get this straightened > out, so this should be no reason to delay the branch. > -- > Jim Wilson, GNU Tools Support, http://www.specifix.com > > > ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Binutils 2.18 prep 2007-07-30 18:09 ` Binutils 2.18 prep Daniel Jacobowitz 2007-07-30 18:14 ` H.J. Lu 2007-08-01 17:57 ` Jim Wilson @ 2007-08-06 21:13 ` Daniel Jacobowitz 2007-08-07 8:18 ` Add bfin-*rtems* [was: Binutils 2.18 prep] Ralf Corsepius 2007-08-09 11:45 ` Binutils 2.18 prep Matthias Klose 2 siblings, 2 replies; 38+ messages in thread From: Daniel Jacobowitz @ 2007-08-06 21:13 UTC (permalink / raw) To: binutils On Mon, Jul 30, 2007 at 12:51:46PM -0400, Daniel Jacobowitz wrote: > Hi folks, > > Obviously that didn't happen. Let's try again. If you know of any > issues in HEAD that should not be in a stable release, please let me > know. Otherwise, I will tentatively plan: > > - Branch 6th August > - Release 27th August This time, it did happen. I have created the new branch, binutils-2_18-branch. There is a snapshot from the branch in the snapshots directory on sourceware, which I have forwarded to the Translation Project. As usual, for the next two weeks or so please feel free to apply bug fixes to the branch when you apply them to HEAD. Thanks! -- Daniel Jacobowitz CodeSourcery ^ permalink raw reply [flat|nested] 38+ messages in thread
* Add bfin-*rtems* [was: Binutils 2.18 prep] 2007-08-06 21:13 ` Daniel Jacobowitz @ 2007-08-07 8:18 ` Ralf Corsepius 2007-08-07 9:33 ` Nick Clifton 2007-08-09 11:45 ` Binutils 2.18 prep Matthias Klose 1 sibling, 1 reply; 38+ messages in thread From: Ralf Corsepius @ 2007-08-07 8:18 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: binutils, Joel Sherrill [-- Attachment #1: Type: text/plain, Size: 538 bytes --] On Mon, 2007-08-06 at 17:12 -0400, Daniel Jacobowitz wrote: > On Mon, Jul 30, 2007 at 12:51:46PM -0400, Daniel Jacobowitz wrote: > > Hi folks, > This time, it did happen. I have created the new branch, > binutils-2_18-branch. > As usual, for the next two weeks or so please feel free to apply > bug fixes to the branch when you apply them to HEAD. Thanks! I'd appreciate it, if somebody could apply the patch below to the branch and HEAD. It's the only rtems-specific patch currently missing from upstream for rtems ;) TIA, Ralf [-- Attachment #2: binutils-rtems-20070807-1.diff --] [-- Type: text/x-patch, Size: 686 bytes --] 2007-08-07 Ralf Corsépius <ralf.corsepius@rtems.org> * configure.tgt: Add bfin-*rtems*. diff -uNr binutils-2.17.90.orig/ld/configure.tgt binutils-2.17.90/ld/configure.tgt --- binutils-2.17.90.orig/ld/configure.tgt 2007-08-06 22:00:19.000000000 +0200 +++ binutils-2.17.90/ld/configure.tgt 2007-08-07 08:42:24.000000000 +0200 @@ -113,6 +113,10 @@ targ_extra_emuls="elf32bfinfd" targ_extra_libpath=$targ_extra_emuls ;; +bfin-*-rtems*) targ_emul=elf32bfin; + targ_extra_emuls="elf32bfinfd" + targ_extra_libpath=$targ_extra_emuls + ;; bfin-*-uclinux*) targ_emul=elf32bfin; targ_extra_emuls="elf32bfinfd" targ_extra_libpath=$targ_extra_emuls ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Add bfin-*rtems* [was: Binutils 2.18 prep] 2007-08-07 8:18 ` Add bfin-*rtems* [was: Binutils 2.18 prep] Ralf Corsepius @ 2007-08-07 9:33 ` Nick Clifton 0 siblings, 0 replies; 38+ messages in thread From: Nick Clifton @ 2007-08-07 9:33 UTC (permalink / raw) To: Ralf Corsepius; +Cc: Daniel Jacobowitz, binutils, Joel Sherrill Hi Ralf, > I'd appreciate it, if somebody could apply the patch below to the branch > and HEAD. It's the only rtems-specific patch currently missing from > upstream for rtems ;) Done. Cheers Nick ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Binutils 2.18 prep 2007-08-06 21:13 ` Daniel Jacobowitz 2007-08-07 8:18 ` Add bfin-*rtems* [was: Binutils 2.18 prep] Ralf Corsepius @ 2007-08-09 11:45 ` Matthias Klose 2007-08-13 0:33 ` Daniel Jacobowitz 1 sibling, 1 reply; 38+ messages in thread From: Matthias Klose @ 2007-08-09 11:45 UTC (permalink / raw) To: binutils Daniel Jacobowitz schrieb: > On Mon, Jul 30, 2007 at 12:51:46PM -0400, Daniel Jacobowitz wrote: >> Hi folks, >> >> Obviously that didn't happen. Let's try again. If you know of any >> issues in HEAD that should not be in a stable release, please let me >> know. Otherwise, I will tentatively plan: >> >> - Branch 6th August >> - Release 27th August > > This time, it did happen. I have created the new branch, > binutils-2_18-branch. There is a snapshot from the branch in the > snapshots directory on sourceware, which I have forwarded to the > Translation Project. > > As usual, for the next two weeks or so please feel free to apply > bug fixes to the branch when you apply them to HEAD. Thanks! I see patches sent to the ML labeled as bug fixes, but they are not applied to the branch. Could these bug fixes be applied to the branch as well? http://sourceware.org/ml/binutils/2007-08/msg00115.html http://sourceware.org/ml/binutils/2007-08/msg00116.html http://sourceware.org/ml/binutils/2007-08/msg00120.html http://sourceware.org/ml/binutils/2007-08/msg00121.html Matthias ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Binutils 2.18 prep 2007-08-09 11:45 ` Binutils 2.18 prep Matthias Klose @ 2007-08-13 0:33 ` Daniel Jacobowitz 0 siblings, 0 replies; 38+ messages in thread From: Daniel Jacobowitz @ 2007-08-13 0:33 UTC (permalink / raw) To: binutils On Thu, Aug 09, 2007 at 01:45:17PM +0200, Matthias Klose wrote: > I see patches sent to the ML labeled as bug fixes, but they are not applied to > the branch. Could these bug fixes be applied to the branch as well? > > http://sourceware.org/ml/binutils/2007-08/msg00115.html SSE4 fixes in Intel mode. I don't think this is especially important for the branch, but it isn't harmful either, so I merged it. > http://sourceware.org/ml/binutils/2007-08/msg00116.html This thread appears to be a dud. > http://sourceware.org/ml/binutils/2007-08/msg00120.html Alan has already applied this to the branch. > http://sourceware.org/ml/binutils/2007-08/msg00121.html Ditto. -- Daniel Jacobowitz CodeSourcery ^ permalink raw reply [flat|nested] 38+ messages in thread
end of thread, other threads:[~2007-08-13 0:33 UTC | newest] Thread overview: 38+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2007-03-22 2:48 Binutils 2.18 prep Daniel Jacobowitz 2007-03-22 10:06 ` SVN for src (was Re: Binutils 2.18 prep) Andrew STUBBS 2007-03-22 10:45 ` Diego 'Flameeyes' Pettenò 2007-03-22 11:06 ` Andrew STUBBS 2007-03-22 11:23 ` Diego 'Flameeyes' Pettenò 2007-03-22 14:07 ` Paul Brook 2007-03-22 14:20 ` Andrew STUBBS 2007-03-22 14:31 ` Joseph S. Myers 2007-03-22 14:11 ` Bob Rossi 2007-03-22 14:17 ` Daniel Jacobowitz 2007-03-22 15:00 ` Daniel Jacobowitz 2007-03-22 15:28 ` Daniel Jacobowitz 2007-03-22 15:51 ` Andrew STUBBS 2007-03-26 14:59 ` Daniel Jacobowitz 2007-03-26 16:32 ` Andrew STUBBS 2007-04-10 17:25 ` Daniel Jacobowitz 2007-04-11 10:22 ` Andrew STUBBS 2007-04-11 11:06 ` Daniel Jacobowitz 2007-04-11 13:46 ` Paul Koning 2007-04-11 14:18 ` Ian Lance Taylor 2007-04-11 15:00 ` Daniel Jacobowitz 2007-04-11 15:23 ` Ian Lance Taylor 2007-03-22 15:35 ` Andrew STUBBS 2007-03-22 16:48 ` DJ Delorie 2007-03-22 17:08 ` Andrew STUBBS 2007-03-22 18:15 ` DJ Delorie 2007-03-23 9:12 ` Andrew STUBBS 2007-03-26 14:57 ` Daniel Jacobowitz 2007-03-26 15:16 ` Daniel Jacobowitz 2007-07-30 18:09 ` Binutils 2.18 prep Daniel Jacobowitz 2007-07-30 18:14 ` H.J. Lu 2007-08-01 17:57 ` Jim Wilson 2007-08-02 0:08 ` l l 2007-08-06 21:13 ` Daniel Jacobowitz 2007-08-07 8:18 ` Add bfin-*rtems* [was: Binutils 2.18 prep] Ralf Corsepius 2007-08-07 9:33 ` Nick Clifton 2007-08-09 11:45 ` Binutils 2.18 prep Matthias Klose 2007-08-13 0:33 ` Daniel Jacobowitz
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).