On Tue, Sep 20, 2016 at 12:22:47AM -0600, Kevin Locke wrote: > 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 > > > configurator. > > > > > > To support such compilers, pass the output flag as the last flag to the > > > configurator. > > > > > > 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 > > each other. > > > > 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?
I think that's a better option, and maybe the way to go in the short term. Longer term, I'm wondering if we want some sort of mini-library for shared use by the ccan tools - configurator, ccanlint, etc. Amongst other things that could have an "invoke compiler" function which abstracts this sort of thing in a more general way. Of course, this borders on the questions about use of err() etc. in the configurator - within the tools themselves, what can we and can't we assume about the system. > 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. > > Thoughts? --output-cflag is kind of clunky, but again might be our best bet in the short term. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
_______________________________________________ ccan mailing list ccan@lists.ozlabs.org https://lists.ozlabs.org/listinfo/ccan