[ ant-contrib-Bugs-1715475 ] CC, aCC, and xlC compilers don't bid on assembly files (.s)

"SourceForge.net" <[email protected]> Wed, 22 Aug 2007 14:09:27 -0700
Newsgroups gmane.comp.java.ant-contrib.devel
Message-ID <[email protected]>
Bugs item #1715475, was opened at 2007-05-09 06:25
Message generated for change (Comment added) made by darius42
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=416920&aid=1715475&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: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: David Haney (darius42)
>Assigned to: David Haney (darius42)
Summary: CC, aCC, and xlC compilers don't bid on assembly files (.s)

Initial Comment:
The CC (Sun), aCC (HP), and xlC (IBM) compiler adapters do not bid on assembly files.  Instead, they defer to the sourceExtensions defined in the GccCompatibleCCompiler definition (which doesn't include '.s').  

In addition, since these compiler adapters are bidding based on the GccCompatibleCCompiler definition, they are bidding on Fortran source files (.f, .for), even though the underlying compilers can't deal with them.

Attached is a proposed patch which moves the sourceExtension and headerExtension definitions into the derived adapters for each of the compilers in question, along with the start of a testsuite for each compiler (currently just verifying which files they bid on).

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

>Comment By: David Haney (darius42)
Date: 2007-08-22 21:09

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

Committed patch bidExtensions3.diff in revision 139.

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

Comment By: David Haney (darius42)
Date: 2007-08-17 18:03

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

File Added: bidExtensions3.diff

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

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

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

I want to avoid tying this issue (bidding on '.s' files) with the
secondary issues that were also raised.  I've opened two new issues for
tracking the secondary issues, and have copied the original question and
initial responses to those issues into the new bugs:

1718197  Should Sun CC bid on .c++ files
1718198  CC, xlC file bids are case-insensitive

I've also updated the proposed change for this issue so that it assumes
case-insensitive file compares and that .c++ is supported by Sun CC (this
was the behavior when it was inheriting sourceExtensions from
GccCompatibleCCompiler).
File Added: bidExtensions2.diff

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

Comment By: Curt Arnold (carnold)
Date: 2007-05-11 18:11

Message:
Logged In: YES 
user_id=27193
Originator: NO

1. Maybe a half-hearted bid (something like DEFAULT_PROCESS_BID/2), so if
no other compiler makes a full bid, then it will get a chance on the file. 
Better for a compiler that might be able to process it gets it than the
linker (which gets all unbid files).

2. Nope

3. 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-09 06:38

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

I have a couple of open questions associated with the attached patch:

1) The behavior of the Forte CC compiler changed with Forte 6.1 (Sunpro
5.2).  Prior to Forte 6.1, the .c++ extension was not supported (and the
compiler would reject it as an unknown file type).  With 6.1 and later, the
.c++ extension is supported.  So should the Forte adapter bid on .c++ files
(since they are currently supported) or not (since some compiler versions
won't be able to handle them).

2) The test suite only verifies that all of the files that are explicitly
supported are bid on, it doesn't test the behavior for files that it
shouldn't bid on.  Is there a recommended process for testing that
unrecognized extensions won't be bid on?

3) 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).

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

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

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/