Hi. I am not sure I understand your concern. Whether an MPIR build uses the normal or the debug libraries is set by mpir_config.py.
I'll try to explain about UseDebugLibrary. Let's consider some vcxproj generated by AppWizard. It consists of several parts. Part 1) At the beginning it declares ProjectConfigurations - Platform and Configuration. Platform should be one of predefined keywords: Win32, x64, ARM. But Configuration can be any mixture of letters and digits: for example Debug, Deb, Rel, Debug_Static, ReleaseDynamic and so on. It's just a name. By default project has two configurations with names Debug and Release. Part 2) Vcxproj imports a Microsoft.Cpp.Default.props file. It's one of Microsoft system MsBuild files (let call them "MSProps"). These files locates (at my computer) in "c:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120" and have extensions *.props and *.targets. MsProps are rather large complex scripts, written in BsBuild language. They contains property and item declarations, import directives. Many of them are conditional, i.e. depends on some property value. They also contains a lot of function calls (MsBuild and .Net). So it is difficult to understand them in details. In short Microsoft.Cpp.Default.props will prepare many common properties and items for our project. Part 3) Vcxproj declares some primary properties for each ProjectConfiguration. These properties are: <ConfigurationType>, <PlatformToolset> (default value is 'v100', so it may be omited in Msvc 10), <CharacterSet> (default value is 'Unicode' since Msvc 11), and <UseDebugLibraries>. These primary properties serves as a description of each ProjectConfiguration. Part 4) After that vcxproj imports Microsoft.Cpp.$(Platform).user.props. This MSProps will tune the environment for ProjectConfiguration, setup many properties and items, specific for each ProjectConfiguration. How does it know what values are suitable for this ProjectConfiguration? MSProps get this information from primary properties, that ware declared in Part 3. If this ProjectConfiguration intended for debugging, MSProps will set properties and items for disabling optimization, generating DebugInfo and so on. And how MSProps get to know whether this ProjectConfiguration intended for debugging? Via property <UseDebugLibraries>. The name "UseDebugLibraries" may be confusing, it's not at all correct. In fact, UseDebugLibraries is just a flag to distinguish Debug and Release configurations. Part 5) This part has ItemDefinitionGroups that specify Item metadata for compiling, linking and so on. But all these metadata are already set by MSProps imported in Parts 2 and 4. So if we remove this part 5, the project probably will compile, builds and run, in all ProjectConfigurations. Because default settings, made by MSProps, are rather good and appropriate for every ProjectConfigurations. But often we need to overwrite some of these metadata (for example, IntermediateDir and OutputDir) or add something (for example, preprocessor definitions). We can do it in this part of the vcxproj, or we can do it in our own *.props file(s) and import them from vcxproj. It is desirable to have <UseDebugLibraries> in vcxproj - it provides useful information for imported MSProps, so they could do their work better. What happen if vcxproj has no <UseDebugLibraries>? MSProps will not know that some ProjectConfigurations are intended for debugging. It will consider all ProjectConfigurations as release - turn on optimization, skip debug info, etc. So I think it worth to add <UseDebugLibraries> to both new-style and old-style projects. I had rather hoped that the two solutions could be merged ... As for solution merging, I suppose I don't understand it. Old-style solution file is just a list of old-stile projects and new-style solution file is a list of new-stile projects. Old-style and new-style solution files are quite the same. How we can merge them? Do you intend to put both old-stile and new-stile projects into the same solution? Yes, it's possible if projects have different names. For example, new-style projects will have a '_p' suffix, as it was previously. But is that a good idea? I think that a large solution with duplicate projects will confuse users. But I am much less convinced about the merits of moving all properties into property sheets. With old approach each project file contains about 20 settings per each ProjectConfiguration. With new approach we have about 20 property sheets, with 1-2-3 settings in each. Also props files has clear names (it's clear, what settings are in common.dll.debug.props) and all located in one place - props_common directory. And projects contain no settings - only primary properties. I suppose two building approaches may exist concurrently. User accustomed to old approach could use old solutions as the did previously. Best regards, Sergey. PS I failed to send you an e-mail: Address or domain has been blocked by recipient -- 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.
