[ccan] [PATCH v2 00/13] configurator: Support for Windows and MSVC
Kevin Locke
kevin at kevinlocke.name
Wed Sep 28 16:28:03 AEST 2016
On Tue, 2016-09-27 at 15:23 +1000, David Gibson wrote:
> On Thu, Sep 22, 2016 at 09:33:03PM -0600, Kevin Locke wrote:
>> This is the second revision of my patch series which adds support for
>> building configurator with Microsoft Visual C++ and running it on
>> Windows. The motivation is to add sufficient support for Windows to
>> allow using header-only modules with minimal hassle.
>
> Thanks for sending again. I've applied a number of the simpler ones
> already. The remainder I still have some comments on.
Thanks for reviewing again! I think I've addressed everything, but if
there is anything I've overlooked, let me know.
> Incidentally you are introducing a new concept here which isn't really
> comment on. The use of more #ifdefs on system macros into
> configurator means that the way our default compiler options will be
> set up is basically going to be dependent on the setup used to compile
> configurator itself.
>
> That seems like a sensible approach to me; we just need to be a bit
> careful of interactions with make and/or other build systems when we
> could have a system with multiple compilation options (e.g. both MSVC
> and cygwin/gcc installed on a Windows machine).
That is a good point and probably deserves some more thought and
discussion. I've tried to keep most additions configurable at
run-time (e.g. the new -O configurator flag) so if the compile-time
deduction is wrong it can be overridden. But it still changes the
configurator behavior based on how it was compiled without any
explicit configuration. That may or may not be desirable. Has there
been any discussion of being more explicit about specifying build vs
host system at build time? Anything in particular you have in mind?
A good example of something which can not be overridden at runtime is
the directory separator passed to popen(3). I don't think there are
currently any problems, but the choice of directory separator could
easily cause problems between Cygwin and native binaries in other
situations. Definitely worth thinking about.
Cheers,
Kevin
More information about the ccan
mailing list