On 09/19/2016 11:23 PM, David Gibson wrote:
On Sun, Sep 18, 2016 at 06:52:05PM -0600, Kevin Locke wrote:
Unfortunately, not all compilers support -o as a command-line option for
specifying the output file. Visual Studio cl.exe issues warning D9035
when -o is given, which is detected as a compile warning by the
To support such compilers, pass the output flag as the last flag to the
This is a breaking change. Existing scripts which pass flags to the
compiler must be modified to add "-o" as the last flag. As noted in the
cover letter for this patch series, I'm open to considering alternatives
if this is unacceptable.
So, as it stands, this change completely breaks ccanlint on POSIX,
which is not ok. Specifically it looks like the problem is that the
DEFAULT_FLAGS from the configurator make it into CCAN_CFLAGS in
config.h. ccanlint then tries to add further options and its own -o
to the end of that, which isn't going to work.
In short, I think the problem is that ccanlint needs fixes to work
with MSVC (and possibly anything much else apart from gcc). I think
we need to look at how to fix that and the configurator together with
Not having working ccanlint on Windows seems like a pretty big, since
its the main tool for testing ccan, amongst other things.
Good catch. I hadn't noticed the ccanlint breakage. That was a big
oversight on my part.
The breakage likely extends to any other programs which use CCAN_CFLAGS,
since none are expecting the output flag at the end. Perhaps a better
solution would be to emit the output flag as a separate macro.
Something like CCAN_OUTPUT_CFLAG. What do you think?
The command line API for configurator could either expect the output
flag to be the last argument as currently in the patch (which is a
breaking change for anything which call it). Or a command line option
such as --output-cflag could be added to specify the flag and preserve
command-line syntax compatibility.
ccan mailing list