On 06/11/2015 21:44, SeVlaT wrote:
>
> 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.
>
[snip]
Hi Sergey,
> 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.
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, which means that we don't need <UseDebugLibraries>.
Nevertheless, I don't think it would do any harm to add it.
>> 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.
Yes, but these properties are not managed in the project files, which
are all autogenerated from a single mpir_config.py file for each MSVC
version. So to change a property all that is necessary is to modify the
relevant mpir_config.py file. 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. Here your use of $(IntDir)\dum\my\%(RelativeDir) is a
brilliant approach and one that I intend to adopt. This has a big effect
since it impacts on every source file line whereas other properties are
not subject to such a big text expansion factor in the vcxproj files.
Also the rationalisation of mpir_config.py into orthogonal components
has been on my todo list for some time.
> 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.
I am doubtful about adding two approaches for the Windows build as a
part of the standard MPIR distribution. 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.
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.
The first of these options is certainly possible but it will be quite
some time before I will get to a point where I am ready to contemplate
such a switch.
However I would not personally be adverse to passing the maintainer role
to you if you are in a position to commit to undertake it in the long
term (subject, of course to this being acceptable to the MPIR team).
And, of course, for now we could simply advertise the fact that you are
offering an alternative MSVC build in your GIT repository.
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.
