a On Saturday, 7 November 2015 22:50:22 UTC, SeVlaT wrote: > > Hi. > > This becomes an issue if people don't explicitly specify the libraries >> that they are going to use. But in our case we explicitly set up the >> correct libraries for Release and Debug so we don't make any use of the >> MSProps defaults, > > > Nevertheless you do make use MSProp, because all your projects imports > MSProp. MSProp does a lot of work. > You explicitly set _some_ settings, so you overwrite _some_ MSProp default > settings. > You may not be sure that you overwrote _all_ settings. So your project > probably use _some_ default settings. > > I don't like when vcxproj contain many properties - I prefer move them out > of vcxproj to property sheets. Nevertheless I recommend to put > <UseDebugLibraries> into vcxproj, along with other primary properties. > > >> Here I do think your adoption of a common >> mppir_config.py across different MSVC versions is a good one which I >> intend to look at. >> >> There are also good reasons for adopting a common overall props file for >> those properties that bring significant simplifications of the >> vcxproject files. > > > I'm glad that you appreciate some of my ideas. > > >> ... whereas other properties are >> not subject to such a big text expansion factor in the vcxproj files. >> > > I agree that new approach has some demerits: it requires a number of > *props files and also a _project.prop, that contain special primary > properties. This structure may be rather complex for users - not all of > them are familiar with PropertySheets. > > So you may be right and project settings should be defined in vcxproj > rather than in props. > > >> Also the rationalisation of mpir_config.py into orthogonal components >> has been on my todo list for some time. >> > > >> I am doubtful about adding two approaches for the Windows build as a >> part of the standard MPIR distribution. > > > I do not insist on it. You may borrow any of my ideas and use them to > improve existing build system. > > Most people just want to build >> MPIR 'out of the box' so adding two approaches that do the same thing >> from their perspective doesn't add much real value. It would be better >> to offer one or the other. >> > > So there will be only one approach in official repo. > And my repo would have another approach (or both). This repository will be > an alternative for geeks. > > >> >> And in order to switch to your approach either I would have to adopt it >> or you would have to make a long term commitment to become the Windows >> build maintainer for MPIR. >> > > I suppose I'm not ready to be an MPIR maintainer for years. > > > Most people just want to build MPIR 'out of the box' >> > > I'd like to draw your attention to one feature of new approach. It allow > user to embed his own property sheet into building process by using MSBUILD > command line (without modifying any file). > > User can make a *.props file, and put a path to it into > MPIR_Props_External property. > Overall.props checks if MPIR_Props_External is set and if the > MPIR_Props_External value is a path to an existing file. In such case it > import this property sheet _after_ all other property sheets. So user can > overwrite any project setting. > > Example: > msbuild /P:MPIR_Props_External=d:\Work\extended.props > mpir\build.vc11.p\lib_mpir_gc\lib_mpir_gc.vcxproj > > I suppose it worth to add this feature into existing build approach. > > For example, I need to compile lib_mpir_gc with /MD (/MDd) switch. Just > 'out of the box'. > Unfortunately t was impossible. I had to manually modify > lib_mpir_gc.vcxproj. > > Best regards, > Sergey >
Hi Sergey, Just to let you know that I have adopted quite a few of your ideas in the standard MPIR Visual Studio build. The new version is in my GitHub repository at: https://github.com/BrianGladman/mpir The build directory structure now matches your own and mpir_config has been split into components. Also, in principle, mpir_config.py now supports all recent Visual Studio versions although I am only testing this on VS 2015 at the moment. However I have not adopted an approach that relies on property sheets to the extent that you have done. Instead I use only four common property sheets for lib/release, lib/debug, dll/release and dll/debug. I should also mention that the python script for reading and creating solution files (*.sln) is completely new as the old one had some serious bugs in it. Although I have not yet looked at it seriously, the common configuration may now make it possible to support your complete property sheet approach from the same python scripts with an input option to select it. best regards, Brian -- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at http://groups.google.com/group/mpir-devel. For more options, visit https://groups.google.com/d/optout.
