From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: Alan Modra Cc: binutils@sources.redhat.com, gdb-patches@sources.redhat.com Subject: Re: bfd_read and bfd_write Date: Wed, 05 Sep 2001 20:03:00 -0000 Message-id: <3B96E752.8030205@cygnus.com> References: <20010905145037.K13524@bubble.sa.bigpond.net.au> <3B965696.70401@cygnus.com> <20010905122109.A17937@redhat.com> <3B96C2B2.8050409@cygnus.com> <20010906112244.C24712@bubble.sa.bigpond.net.au> X-SW-Source: 2001-09/msg00059.html > I have patches for all of bfd, gas, gdb. Shouldn't be more than half an > hour checking them all in, unless my net connection breaks or something. > I tend to agree with rth that it's better to break things temporarily > and force use of a new interface than leave compatibility code around, > unless it's a major effort to change over. > > Of course, you could force me to leave the old code in by witholding > permission to make the changes to gdb. [:-)] could i suggest taking a step back and deciding what bfd's policy is going to be on public / external interfaces. remember, bfd is a library used by more than gdb and the other code immediately to hand. i don't think changing public / external interfaces should be taken lightly (are you bumping the shlib version?). i'd strongly recommend at least changing the function name as well as the function signature - that way old code can't pick up the new interface. i'd also prefer to have the old interface around for at least a wee bit (allow mix 'n' match) of new bfd, old ... and give the change a chance to propogate / settle. this also guarentees that gdb continues to _always_ be buildable. i'm also some what puzzled as to why this all has to be done as a single jumbo patch, three separate patches (add new, change, delete old) are surely easier. if you want, i can also add a check to gdb that ensures that the old function isn't used. enjoy andrew