oblems.
If you would like to help with that please contact me.
--
Nathanael Nerode <[EMAIL PROTECTED]>
[Insert famous quote here]
Daniel Jacobowitz wrote:
>If you want to update libtool, you get to play the all-of-src-uses-it
>game. I have been updating src directories to more recent autoconf
>versions in the hope of getting rid of our outdated libtool someday. I
>believe the only remaining holdout is newlib, but I didn't ch
Paul Koning wrote:
>>>>>>"Nathanael" == Nathanael Nerode <[EMAIL PROTECTED]> writes:
>
>
> Nathanael> * pdp11-*-* (generic only) Useless generic.
>
> I believe this one generates DEC (as opposed to BSD) calling
> conventions, so I'd r
Jan-Benedict Glaw wrote:
> On Sun, 2005-06-05 12:41:43 -0400, Nathanael Nerode <[EMAIL PROTECTED]> wrote:
>
>
>>* vax-*-bsd*
>>* vax-*-sysv*
>> If anyone is still using these, GCC probably doesn't run already. I
>> certainly haven't seen an
Mark Mitchell wrote:
> Daniel Jacobowitz wrote:
>
>> On Sun, Jun 05, 2005 at 12:41:43PM -0400, Nathanael Nerode wrote:
>>
>>> * mips-wrs-windiss
>>> * powerpc-wrs-windiss
>>> I don't think these were supposed to be in the FSF tree at all, were
&
OK, here's my proposed obsoletion list.
* arc-*-elf* (only arc port)
No maintainer. Still.
* alpha*-*-unicosmk*
No real update since 2002. If rth, the lone alpha maintainer, is actually
maintaining it, I guess it should stay; it's not in bad shape. But does
it really need fixproto?
*
So here are the targets using fixproto. I've attempted to classify them.
Very tentatively. Fixproto is very nice in some ways, but it's only necessary
on systems with quite old system headers, and it interacts in a confusing and
obnoxious way with fixincludes, which prevents some highly desirable
Well!
I really like Zack's proposed conversion plan in the PDF,
but particularly the order, and of that particularly the early stages.
I see no problem with the "top level" separation into entirely distinct
base classes, of the sort which require explicit work to treat as a union.
And I don't see
Arno commented in a bug report:
> Also, having the TOOLS_TARGET_PAIRS being now set in configure.ac is
> more painful to maintain than having the list in Makefile.in, what about
> reverting this change ? It would make life simpler when adding support
> for a new target (no need to worry about reru
Apologies for committing. I committed before I heard from you saying
"No, don't", but apparently well after you had sent the message. My mail
receiving must have been a bit off. :-/
Indeed, as I see from another message, you considered putting "part 1" as
an early project and "part 2" as a stag
Just to be clear, I do not want to criticize Mark or the Project system in
general. I quite *like* the project sequencing idea. I submitted the
libada-gnattools-branch project as two phases, and I think any major changes
from the second phase are perfectly suited to wait for stage 2. Furthermore
>>Nathanael Nerode wrote:
It's in now, BTW. Nothing broke. :-) (As I notified when I submitted the
patch as an FYI prior to stage 1 opening, this was checked with a native
bootstrap *and* a cross build.)
>>The libada-gnattools-branch suffers severely from having to b
This is clearly false.
Could someone fix it?
--
This space intentionally left blank.
The libada-gnattools-branch suffers severely from having to be maintained
in parallel with mainline (since it's a rearrangment of existing code).
Another two months of waiting will necessitate many hours of totally
unneccessary work on my part.
The longer the existing portion remains on a branch,
I would like a clear distinction between correctness tests and optimization
tests. At the moment they are being intermixed, often without comment. :-(
This makes the testsuite somewhat less useful than it should be.
Any suggestions on a good policy for this?
--
This space intentionally left bl
>In practice everyone uses round to nearest even.
Not when implementing interval arithmetic or affine arithmetic, etc.
--
This space intentionally left blank.
First of all, I totally approve of moving to Subversion.
Daniel Berlin wrote:
>I also plan on excluding merge tags
It's not safe to exclude the most recent mergepoint tag for
a live branch. We will lose necessary information for the next
merge to that branch.
You wrote elsewhere:
>Find the curr
17 matches
Mail list logo
