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 -- 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.
