On 28 September 2012 17:40, Brian Gladman <b...@gladman.plus.com> wrote: > -----Original Message----- From: Brian Gladman > Sent: Friday, September 28, 2012 5:18 PM > > To: mpir-devel@googlegroups.com > Subject: Re: [mpir-devel] Possible Issue with the Windows command lIne > build? > > -----Original Message----- From: Bill Hart > Sent: Friday, September 28, 2012 5:07 PM > To: mpir-devel@googlegroups.com > Subject: Re: [mpir-devel] Possible Issue with the Windows command lIne > build? > > On 28 September 2012 16:36, Brian Gladman <b...@gladman.plus.com> wrote: >> >> -----Original Message----- From: Bill Hart >> Sent: Friday, September 28, 2012 4:16 PM >> To: mpir-devel@googlegroups.com >> Subject: Re: [mpir-devel] Possible Issue with the Windows command lIne >> build? >> >> >> I don't know very much about the command line build. But I am not >> really in favour of option 1. >> >> I don't see why option 3 is a problem. However, it depends. Is the cfg >> file different per architecture? Would it automatically find the right >> one if they were all there in their respective directories? >> >> ==================== >> >> The problem is just the overhead of producing them and keeping them up to >> date. >> >> They are generated automatically by the Visual Studio build generator so >> someone has to build every possible architecture variation to set up all >> of >> them. >> >> The Visual Studio build in MPIR is now very different to that supplied >> earlier. Apart from a small number of pre-configured builds, a user now >> has >> to run a Python program and select the architecture for which they wish to >> build. This then produces a number of files needed for building with >> Visual >> Studio, after which MPIR for the selected architecture can be built using >> the Visual Studio IDE. The necessary cfg.h files are built as a part of >> this process. > > > I see. > >> >> I can do this and add them if we want to adopt this solution but it means >> in >> effect that I end up partly supporting the command line build, a task that >> I >> am not really keen to take on. However, I can do it as a 'one off' >> provided I am not then committed to provide on-going support for it. > > > You'll have to give me a list of all the .cfg files, as I will have to > add them to the distribution mechanism, otherwise they won't be in the > release tarball. > > It is possible to construct a script which generates them all in one go? > > =========================== > > Yes, that's a good idea. I think I can probably do this by stripping out > stuff from my normal build generator (it will be a Python script though). > > =========================== > > Its such a good idea that I have already done it! > > In the big gap in MPIR development progress, I had completely forgotten > about solving this problem over a year ago. > > So all that has to happen is that anyone building the command line build has > to run mpir_config.py only once and all the cfg.h files are generated. > > So we can either (a) add all these files to distributions, (b) document the > need to run mpir_config.py once before any Windows command line build, or > (c) run a slightly modified mpir_config.py from the command line build > script. >
I now like either b or c. But I'll leave it up to you to decide. Of course the other option is to test for the existence of a cfg file. If none is found, report to the user that they must first run mpir_config.py and abort. We can then document this. Bill. -- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
