>>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
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
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
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
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
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
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?
*
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
&
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
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
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
oblems.
If you would like to help with that please contact me.
--
Nathanael Nerode <[EMAIL PROTECTED]>
[Insert famous quote here]
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
>In practice everyone uses round to nearest even.
Not when implementing interval arithmetic or affine arithmetic, etc.
--
This space intentionally left blank.
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
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,
This is clearly false.
Could someone fix it?
--
This space intentionally left blank.
17 matches
Mail list logo
