[ ant-contrib-Bugs-1718198 ] CC, xlC file bids are case-insensitive

"SourceForge.net" <[email protected]>
Newsgroups gmane.comp.java.ant-contrib.devel
Message-ID <[email protected]>
Bugs item #1718198, was opened at 2007-05-13 16:26
Message generated for change (Comment added) made by darius42
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=416920&aid=1718198&group_id=36177

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: cpptasks
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: David Haney (darius42)
Assigned to: Curt Arnold (carnold)
Summary: CC, xlC file bids are case-insensitive

Initial Comment:
This issue was originally raised in Bug 1715475: 

Based on some experiments, it looks like the extension comparison is case-insensitive (for all platforms), however at least some of the compilers I tested were case-sensitive in their handling of extensions (for example, the Forte compiler will accept a .cpp extension, but will reject a .CPP extension).  Should CC-tasks file matching be case-sensitive or case-insensitive?  Or should it be determined by the compiler (Windows compilers will probably be case-insensitive, while some Unix compilers will be case-sensitive).

Initial response from carnold:

Looks like a debatable decision down in compiler/AbstractProcessor.  Definitely needs to be case-insensitive for the Windows compilers and gcc-like compilers on Windows.  Is there a scenario you have where there is, for example, a compiler that handles ".C" and a different compiler that handles ".c" and the current behavior depends on the order of the bids?  If there was a file that really wanted ".C" files, it could double its bid which would give it prescendence over a compiler that was just matching ".c".  I'd be reluctant to change it until I knew of a harm.

----------------------------------------------------------------------

>Comment By: David Haney (darius42)
Date: 2007-05-13 16:59

Message:
Logged In: YES 
user_id=1140024
Originator: YES

I recall running into an issue with HP where I was unable to use aCC in
order to compile some C files, but the native cc compiler worked okay.  In
that case I would expect .C files to go to the aCC compiler instance, and
.c files to go to the cc compiler.  As long as the comparison is
case-insensitive, it seems like the files would go to one or the other
regardless of the bid priority (If I double the bid for .c in one of the
compilers, that double-bid will apply to .C files as well).

Instead of making the decision in the AbstractProcessor, what about making
that method abstract, and requiring the downstream compiler/linker
implementions define whether they perform their bids in a case-sensitive or
insensitive manner.  For example, all of the Unix compilers could provide
implementations that assume case-sensitive, and be explicit which cases
they support, while the Windows compilers could provide implementations
that assume case-insensitive.  The only one that seems hairy would be gcc,
which may require different behavior depending on the OS, but that could be
resolved for that compiler by checking the platform that we're on.

I don't have a test case for this scenario at the moment, so I can't
verify if this is still an issue, or if there was just a problem with the
library I was attempting to compile at the time.  This probably isn't a
high-priority issue.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=416920&aid=1718198&group_id=36177

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.