I’m assuming lowercase “s”
files are more common. If not, please reply. Given the current state of the
content type support, we have 2 choices with regards to s vs. S.
1. Remove S from the content type. If a
user has S files, he will need to add *.S to the project specific content type.
The way it is now, he would have to add *.s.
2. Don’t use content types in the
assembler tool definition. This would go back to the 2.1 behavior where there
is a fixed set of extensions associated with the assembler.
What do people think is best?
Leo
From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Lott, Jeremiah
Sent: Wednesday, July 27, 2005
10:44 AM
To: CDT General developers list.
Subject: RE: [cdt-dev] ASM
content-type and uppercase S
I didn't try the latest build, but I got
the latest from head and ran self-hosted. You are correct. Capital
"S" files are included. Lowercase "s" files are not.
-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx
[mailto:cdt-dev-bounces@xxxxxxxxxxx] On
Behalf Of Treggiari, Leo
Sent: Wednesday, July 27, 2005
10:41 AM
To: CDT General developers list.
Subject: [cdt-dev] ASM
content-type and uppercase S
Does anyone have a managed make project that includes
assembler source to try with the latest build? I have a suspicion that
with the latest ASM content type description that includes both lowercase s and
uppercase s, and the current Eclipse treatment of content type case insensitivity,
lowercase s files would be not included, by default, in the build.
I’d try it myself if I had a test case.
Thanks,
Leo