On Wed, Sep 28, 2016 at 12:28:03AM -0600, Kevin Locke wrote: > 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.
Right. Can you rebase your current patches and post them as a new
series. That's makes my life easier compared to updated versions of
each patch in various places in the thread.
>
> > 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.
I think it's desirable, on the whole. But having overrides is
generally a good idea too.
> 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?
No, I'm afraid not.
> 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.
Yeah.
--
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
