Hi.
Where can I get new vsyasm version?
They have only 1.3.0, August 10, 2014
http://yasm.tortall.net/Download.html
Yes, I don't think it makes sense to support more than the three most
> recent Visual Studio versions.
>
>
It's reasonable.
Sergey
--
You received this message because you
On 24/11/2015 22:26, SeVlaT wrote:
>
> Do you mean here for four versions of Visual Studio?
>
> Yes. But I see vc10 already have gone.
Yes, I don't think it makes sense to support more than the three most
recent Visual Studio versions.
Brian
--
You received this message because you are
On 24/11/2015 22:26, SeVlaT wrote:
>
> Do you mean here for four versions of Visual Studio?
>
> Yes. But I see vc10 already have gone.
>
> Today I generated all 27 Msvc14 projects and tried to build them
> I've got a lot of errors due to vsyasm cannot understand option "-f Win32".
>
> I fix
> Do you mean here for four versions of Visual Studio?
>
> Yes. But I see vc10 already have gone.
Today I generated all 27 Msvc14 projects and tried to build them
I've got a lot of errors due to vsyasm cannot understand option "-f Win32".
I fixed vsyasm.props to make platform name lowercase
On 24/11/2015 09:38, SeVlaT wrote:
> I have all of them.
>
> What exactly should be tested?
That is a very good quation!
With 27+ varients each combined with both and ,
it is not practical to build and run the tests on Windows even for one
version of Visual Studio without further build automati
I have all of them.
What exactly should be tested?
My variant:
1. Set usecpp=True to generate cxx project
2. Run mpirconfig four times and pass him all numbers 1-26
3. Ensure that all solutions are buildable
--
You received this message because you are subscribed to the Google Groups
"mpir-dev
On 23/11/2015 21:36, SeVlaT wrote:
> Hi.
>
> I have added it now but with a different name (I assume it will
> have the *.props extension anyway).
>
> I've not found this in your repository.
> So I did it in my msvc1 branch and made a new pull request.
>
>
> But I am not sure how t
Hi.
I have added it now but with a different name (I assume it will
> have the *.props extension anyway).
>
I've not found this in your repository.
So I did it in my msvc1 branch and made a new pull request.
> But I am not sure how to test this as I don't normally build with MSBUILD.
>
To c
On 22/11/2015 04:20, SeVlaT wrote:
> For example, the same way as I did in my previous pull request:
> https://github.com/sevlat/mpir/commit/591918b046f251743aa3376df02bfcbd6b2220ca
>
> I can do it again but not now. Maybe tomorrow.
Its OK, I have added it now but with a different name (I assume
For example, the same way as I did in my previous pull request:
https://github.com/sevlat/mpir/commit/591918b046f251743aa3376df02bfcbd6b2220ca
I can do it again but not now. Maybe tomorrow.
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To unsub
On 21/11/2015 21:30, SeVlaT wrote:
> Thank you very much, Brian!
>
> I have observed your commits during this week.
> I see that many files (*.bat, *.c, *.h) was moved to build.vc directory
> and became common. Probably this structure will be much clear and easier
> to support.
>
>> However I hav
Thank you very much, Brian!
I have observed your commits during this week.
I see that many files (*.bat, *.c, *.h) was moved to build.vc directory and
became common. Probably this structure will be much clear and easier to
support.
> However I have not adopted an approach that relies on propert
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
>> MSP
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
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 ? MSProps will
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 d
> There is an issue that needs fixing but, apart from this, it works for me.
>
Good!
> The issue is that your build directories need the file 'cfg.h'
>
I just copied cfg.h from corresponding build.vc directories. Is it correct?
I think, yes, if (add_prebuild==True).
And what about mode "ad
On 03/11/2015 19:14, SeVlaT wrote:
> Thank you for explanation.
> I made two new mpir_config.py files, they generate old-styled and new-styled
> projects.
> You may play with them, they are in build.vc directory in my repository,
> branch msvc_config: https://github.com/sevlat/mpir/tree/msvc_con
> Are you willing to make a commitment to support this alternative build
> approach on an ongoing basis if it was to be added to the MPIR standard
> distribution?
>
During last fortnight I gave a lot of time to MPIR build system. This was
possible because currently I am doing a similar things
On 03/11/2015 19:14, SeVlaT wrote:
> Thank you for explanation.
> I made two new mpir_config.py files, they generate old-styled and new-styled
> projects.
> You may play with them, they are in build.vc directory in my repository,
> branch msvc_config: https://github.com/sevlat/mpir/tree/msvc_con
Thank you for explanation.
I made two new mpir_config.py files, they generate old-styled and new-styled
projects.
You may play with them, they are in build.vc directory in my repository, branch
msvc_config: https://github.com/sevlat/mpir/tree/msvc_config
There is also a readme.txt in this direct
Thank you for explanation.
I made two new mpir_config.py files, they generate old-styled and new-styled
projects.
You may play with them, they are in build.vc directory in my repository, branch
msvc_config: https://github.com/sevlat/mpir/tree/msvc_config
There is also a readme.txt in this direc
On 03/11/2015 10:21, SeVlaT wrote:
> Can anybody explain mpir_config.py command line parameters?
>
> It expect at most one parameter - a number. If it doesn't have a second bit,
> the program will exit after doint allpreliminary job, but before asking user
> about desireble processor architectur
Can anybody explain mpir_config.py command line parameters?
It expect at most one parameter - a number. If it doesn't have a second bit,
the program will exit after doint allpreliminary job, but before asking user
about desireble processor architecture. If it have both bits 1 and 2 the
program
On 30/10/2015 14:33, SeVlaT wrote:
> Thank you.
>
> And yet another error: line 532
>
> yasm_options(plat, ...)
>
> plat here is a tuple, while yasm_options required an element of this tuple.
> As a result, mpirconfig always generate mpn/x86_64w for include path for
> yasm, even for win32 plat
Thank you.
And yet another error: line 532
yasm_options(plat, ...)
plat here is a tuple, while yasm_options required an element of this tuple. As
a result, mpirconfig always generate mpn/x86_64w for include path for yasm,
even for win32 platforms.
Probably should be:
yasm_options(pl, ...)
-
On 28/10/2015 22:03, SeVlaT wrote:
>
> > For information here are the project type ID that I know about so
> far:
> >
> > Solution Folder:2150E333-8FDC-42A3-9474-1A3956D46DE8
> > Visual C/C++ Project: 8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942
> > Visual Basic Project:
> > For information here are the project type ID that I know about so far:
> >
> > Solution Folder:2150E333-8FDC-42A3-9474-1A3956D46DE8
> > Visual C/C++ Project: 8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942
> > Visual Basic Project: F184B08F-C81C-45F6-A57F-5ABD9991F28F
> > Python Project
On 27/10/2015 21:49, Brian Gladman wrote:
> On 27/10/2015 19:36, SeVlaT wrote:
>
> [snip]
>
>> And yet another question.
>> Why build.vc14\mpir_config.py use some new vcxproject guid -
>> {59348fde-2f50-426c-9f74-184aa069c067} (line 638) while all previous
>> mpir_config.py-s used well-known prpj
On 27/10/2015 19:36, SeVlaT wrote:
[snip]
> And yet another question.
> Why build.vc14\mpir_config.py use some new vcxproject guid -
> {59348fde-2f50-426c-9f74-184aa069c067} (line 638) while all previous
> mpir_config.py-s used well-known prpject guid
> {8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}?
Fo
>
> I think you may be working from the wrong repository since if you look
> at the vc14 version of mpir_config.py in my GITHUB repository at:
>
> I think Bill Hart's repository is the same but I will have to check this.
>
> I looked at Bill Hart's repository - build.vc14\mpir_config.py is real
On 27/10/2015 07:09, SeVlaT wrote:
> So,
>
> build.vc10\mpir_config.py -- search in build.vc10
> build.vc11\mpir_config.py -- search in build.vc11
> build.vc12\mpir_config.py -- search in build.vc12
> build.vc14\mpir_config.py -- search in build.vc12?
No, the last one should be:
build.vc14\mpir_
So,
build.vc10\mpir_config.py -- search in build.vc10
build.vc11\mpir_config.py -- search in build.vc11
build.vc12\mpir_config.py -- search in build.vc12
build.vc14\mpir_config.py -- search in build.vc12?
Did I understand correctly?
--
You received this message because you are subscribed to the
On 26/10/2015 22:58, SeVlaT wrote:
> Thank you for a detailed answer.
>
> In general, I totally agree with you.
>
> it would hence
> be desirable to modify mpir_config.py to generate your simpler
> *.vcxproj
> files and also generate any property sheets that contain details that
>
Thank you for a detailed answer.
In general, I totally agree with you.
it would hence
> be desirable to modify mpir_config.py to generate your simpler *.vcxproj
> files and also generate any property sheets that contain details that
> depend on processor architectures. This is certainly poss
On 23/10/2015 23:33, SeVlaT wrote:
> A month ago I tried to compile MPIR. I noticed that *.vcxproj files are very
> heavy in size and contains a lot of redundant parameters. So I decided to
> simplify project files and move all properties to separate *.props files.
>
> That is my Pull Request fo
A month ago I tried to compile MPIR. I noticed that *.vcxproj files are very
heavy in size and contains a lot of redundant parameters. So I decided to
simplify project files and move all properties to separate *.props files.
That is my Pull Request for it:
https://github.com/wbhart/mpir/pull/163
37 matches
Mail list logo
