On Thursday, August 1, 2013 8:39:12 AM UTC+2, degski wrote: > > "Though it seems that building MPIR under VS is harder than on Linux!" > > I'll try and help you out. > > 0. Install VS. > 1. Install yasm following the instructions on the yasm home-page. > 3. Goto MPIR-homepage and download tar-ball. > 4. Get 7zip, install and extract tar-ball in convenient location. > 5. Fire-up VS. > 6. Open sln-file in build folder of MPIR-source. > 7. Select config you would like, debug/release, Win32, x64. > 8. Build, wait 1 minute. > 9. Enjoy. > > It hardly can get any easier than that. > > No harm meant, I was just kidding "you have to download two files rather than one".
> > > On 1 August 2013 00:45, Jean-Pierre Flori <[email protected] > <javascript:>>wrote: > >> >> >> On Wednesday, July 31, 2013 11:26:04 PM UTC+2, Bill Hart wrote: >> >>> >>> >>> >>> On 31 July 2013 18:24, Jean-Pierre Flori <[email protected]> wrote: >>> >>>> Dear all, >>>> >>>> I'm currently working on some pieces of the build system. >>>> I must admit I don't really like the fact that MPIR ships a modified >>>> yasm source tree. >>>> I think it would be cleaner, and easier to maintain, to ship a tarball >>>> and untar it, or to the least a vanilla source tree, possibly patch it and >>>> >>>> then configure/build it if needed (i already added options to use a >>>> system-wide or user-provided yasm, when autotools are used at least). >>>> >>> >>> This should be possible. As far as I know the Windows MSVC build uses a >>> precompiled yasm, not the one in the tree, so everything should be fine if >>> yasm is built separately. >>> >>> The downside is that GMP builds out-of-the-box without requiring one >>> to download a separate assembler. I would abandon yasm for *nix if it were >>> not for the fact that it is much easier for Brian Gladman to convert *nix >>> assembler to Windows format if it is already in Yasm format (Intel format >>> assembler is much more popular that AT&T format on Windows, I believe). >>> >> I didnot mean to not ship Yasm anymore, rather to ship a vanilla one, >> either through a tarball or through a source tree (as of now, but without >> modification if possible). >> Then updating Yasm would be trivial (ok, you might have to rename a >> tarball/directory, or modify a string somewhere). >> >> >>> >>> >>>> A little like what we do in Sage when we patch upstream software (like >>>> MPIR!). >>>> >>>> Do you really need to pass specific options to yasm? or a "generic" >>>> (./configure && make) build would do? >>>> >>> >>> I believe some options are necessarily passed to Yasm. >>> >> With the current setup everything is passed verbatim ... whence the need >> to modify yasm build system, because the vanilla build system will error >> out if unrecognized option (let's say --enable-gmpcompat) are passed. >> >> It's possible to make it so that the top level configure option are >> discarded when going into a subdir. >> It's more of an hack than a real option of autotools but should avoid to >> modify yasm build system. >> That's what I had in mind and why I was asking if there were situation >> where option passed to the main configure script were really relevant to >> yasm (from what I've seen it's not the case, on the contrary we have to >> modify yasm so that it lives with MPIR superfluous options). >> >> >>> >>>> That's important because the main modification I see is to let the >>>> autotools stuff recognize options given to MPIr and automatically passed >>>> to >>>> yasm. >>>> >>> >>> I think the options are not the same as the ones passed to MPIR. But it >>> is such a long time since I worked on this, I don't recall the details. >>> >>> >>>> >>>> My other question is about the VS builds because I never tried them and >>>> feel completely incompetent. >>>> With VS, is yasm always built? >>> >>> >>> As far as I recall, the user downloads a special version of Yasm >>> maintained by Peter Tortall, installs that in a certain location on their >>> Windows, then builds MPIR in Visual Studio. >>> >>> That would be good news for me! >> (Though it seems that building MPIR under VS is harder than on Linux!) >> >> >>> Bill. >>> >>> Is it possible to let VS untar something? or does yasm directory have to >>>> be uncompressed? >>>> >>>> Best, >>>> JP >>>> >>>> -- >>>> 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+...@**googlegroups.com. >>>> To post to this group, send email to [email protected]. >>>> >>>> Visit this group at >>>> http://groups.google.com/**group/mpir-devel<http://groups.google.com/group/mpir-devel> >>>> . >>>> For more options, visit >>>> https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out> >>>> . >>>> >>>> >>>> >>> >>> -- >> 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] <javascript:>. >> To post to this group, send email to [email protected]<javascript:> >> . >> Visit this group at http://groups.google.com/group/mpir-devel. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > > > > -- > Sign the petition: > https://optin.stopwatching.us/<https://optin.stopwatching.us/> > -- 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/groups/opt_out.
