Hi I've tweeked the command line build some more , now you hopefully can run it with a configure make make check make speed make tune make clean
configure on it's own should autodetect cpu type , set up yasm and msvc paths but you can override these settings with --enable-shared --enable-static --disable-shared --disable-static -- ABI64 --ABI32 and --cpu-* for each cpu type (same as linux/mingw64 now) The logic for finding a suitible compiler and yasm is probably not right , I dont know enough about how these things are usally installed on windows. It should work like this. if a compiler is in path and abi is not specified then use that if a compiler is in path and abi matches then use that if VS 10 exists and can be set up with the required abi then use that if VS 8 exists and can be set up with the required abi then use that give up So we still need the logic for VS2005 and the express editions , who has a install of them for testing ? for finding yasm I use if yasm.exe or vsyasm.exe is in path use that if YASMPATH is set then use YASMPATH\yasm.exe or the vsyasm version if vsyasm.exe exists in the VS2010 vc/bin path then use that if vsyasm.exe exists in the VS2010 custom bin path then use that if yasm.exe exists in the VS2008 vc/bin path then use that give up I suppose we could build yasm from the source shipped with MPIR (would need to ship a few generated files) The flags chosen are probably not too hot , and there is no per-cpu optimizations. All the commands have to run in the same shell due to the way MSVC sets up paths. not added any cpu paths for 32bit yet as I dont know how they are built , do they use yasm? , but nothing difficult here. There are a few errors/warnings in the make still , these just get ignored for the mo The c++ lib is just included in mpir.lib or dll , this should be easy to fix make check mpz/reuse fails to build , easy fix to do make check locale test fails to build , same type of fix we use for mingw64 etc make check doesn't stop on error yet as we need to see all the tests for the mo try fails to build do to duplicate defs of the PITA divrem_preinv stuff , this is obsolete and we should replace this code rather than hack the build. Have fun Jason On Mar 31, 1:23 pm, Bill Hart <[email protected]> wrote: > Huh? Why on earth should a linear function cause a runtime stack > overflow? Do we allocate a pile of temporary memory or something? Are > we using TMP_SALLOC regardless of size or something? > > On 30 March 2011 20:49, jason <[email protected]> wrote: > > > > > This warning is a bit worring (and for linux) , although make check passes > > > mpn\generic\andn_n.c(77) : warning C4717: '__gmpn_andn_n' : recursive on all > > control paths, function will cause runtime stack overflow > > > this is for all logic and copy functions , although they are overridden by > > asm functions later > > > Also at the moment I have just put C and C++ into mpir.lib , do we want or > > need to have two separate libs? > > > Thanks > > Jason > > > ----- Original Message ----- From: "jason" <[email protected]> > > To: <[email protected]> > > Sent: Wednesday, March 30, 2011 8:15 PM > > Subject: Re: [mpir-devel] Re: MSVC command line build > > >> Hi > > >> I got the tests/mpz/reuse.c to compile by > > >> defining __STDC__ so that line 158 in tests/mpz/reuse.c uses the ## token > >> concatcation version > > >> /* Really use `defined (__STDC__)' here; we want it to be true for Sun C > >> */ > >> #if defined (__STDC__) || defined (__cplusplus) > >> #define FAIL(class,indx,op1,op2,op3) \ > >> do { \ > >> class##_funcs[indx] = 0; \ > >> dump (class##_func_names[indx], op1, op2, op3); \ > >> failures++; \ > >> } while (0) > >> #define FAIL2(fname,op1,op2,op3) \ > >> do { \ > >> dump (#fname, op1, op2, op3); \ > >> failures++; \ > >> } while (0) > >> #else > >> #define FAIL(class,indx,op1,op2,op3) \ > >> do { \ > >> class/**/_funcs[indx] = 0; \ > >> dump (class/**/_func_names[indx], op1, op2, op3); \ > >> failures++; \ > >> } while (0) > >> #define FAIL2(fname,op1,op2,op3) \ > >> do { \ > >> dump ("fname", op1, op2, op3); \ > >> failures++; \ > >> } while (0) > >> #endif > > >> or should we use a separate || defined(_MSVC) or whatnot? > > >> Thanks > >> Jason > > >> ----- Original Message ----- From: "jason" <[email protected]> > >> To: <[email protected]> > >> Sent: Sunday, March 20, 2011 11:47 PM > >> Subject: Re: [mpir-devel] Re: MSVC command line build > > >>> Cheers > > >>> make try speed tune are all done , and everything runs fine on my setup. > >>> The reason it was so easy is that all I had to do is compile and link , > >>> all > >>> the hard work has already been done by Brian for the GUI build. > > >>> Now to get it to set the paths for the other versions of MSVC , what > >>> about VS2005 ? do we know the paths ,and are the express editions the > >>> same ? > >>> could we call some sort of builtin windows search tool ? > > >>> As to choosing the mpn paths from the cpu type , instead of a python > >>> script to do it , I was thinking of a plain text file which just lists the > >>> cpu's and the paths and flags , and then the parsing can be done in the > >>> native script of the OS > > >>> Jason > > >>> ----- Original Message ----- From: "Cactus" <[email protected]> > >>> To: "mpir-devel" <[email protected]> > >>> Sent: Sunday, March 20, 2011 5:01 PM > >>> Subject: [mpir-devel] Re: MSVC command line build > > >>> On Mar 20, 4:41 pm, "jason" <[email protected]> wrote: > > >>>> ----- Original Message ----- > >>>> From: "Cactus" <[email protected]> > >>>> To: "mpir-devel" <[email protected]> > >>>> Sent: Sunday, March 20, 2011 2:11 PM > >>>> Subject: [mpir-devel] Re: MSVC command line build > > >>>> On Mar 20, 1:19 pm, "jason" <[email protected]> wrote: > >>>> > Also in the batch script , I've assumed that cl.exe and yasm.exe are > > >>>> > at > >>>> > some > >>>> > fixed location , we just need some code to find out where they really > >>>> > > are > >>>> > on > >>>> > the system or we could just assume they are already in PATH. > >>>> > The existing batch script which calls the project/solution files is > > >>>> > still > >>>> > needed if we want to automate testing of the GUI builds. > > >>>> > Jason > > >>>> > ----- Original Message ----- > >>>> > From: "jason" <[email protected]> > >>>> > To: <[email protected]> > >>>> > Sent: Sunday, March 20, 2011 1:12 PM > >>>> > Subject: Re: [mpir-devel] Re: MSVC command line build > > >>>> > >I haven't done the C++ stuff yet , but I can't see it being > > >>>> > > >difficult. > >>>> > > This should also backport to MPIR-2.3 , 2.2 and 2.1 if we want to , > >>>> > > > > this > >>>> > > should be pretty trivial. > > >>>> > > Jason > > >>>> > > ----- Original Message ----- > >>>> > > From: "jason" <[email protected]> > >>>> > > To: <[email protected]> > >>>> > > Sent: Sunday, March 20, 2011 1:02 PM > >>>> > > Subject: Re: [mpir-devel] Re: MSVC command line build > > >>>> > >> Hi > > >>>> > >> In svn , in the directory win there is a MSVC command line build > > >>>> > >> >> that > >>>> > >> is > >>>> > >> independant of MSVC project/solution files. > >>>> > >> This should work on any MSVC , ie 2010 2008 2005? and the free > >> > >>>> > >> versions > >>>> > >> I've done a > >>>> > >> make > >>>> > >> make_clean > >>>> > >> make_check > > >>>> > >> There are still a few minor bits to sort out , at the moment the > > >>>> > >> >> script > >>>> > >> is fixed to nehalem 64 bit build(see below) , a static lib , > >> > >>>> > >> assumes > >>>> > >> stdint is availible , seems to create an endless %PATH% after a > > >>>> > >> >> number > >>>> > >> of > >>>> > >> runs , t-mpz_reuse wont build , t-locale wont build , and a few > > >>>> > >> >> other > >>>> > >> hacks , make try speed tune still to do , but mostly it's there and > >>>> > >> > >> it > >>>> > >> works > > >>>> > >> We need some code to select the mpn path dependant on cpu and this > >>>> > >> could > >>>> > >> be shared with the GUI builds and also Linux if we used python > >> > >>>> > >> say(or > >>>> > >> C) > > >>>> > >> Jason > > >>>> > >> -- > >>>> > >> You received this message because you are subscribed to the Google > >>>> > >> Groups > >>>> > >> "mpir-devel" group. > >>>> > >> To post to this group, send email to [email protected]. > >>>> > >> To unsubscribe from this group, send email to > >>>> > >> [email protected]. > >>>> > >> For more options, visit this group at > >>>> > >>http://groups.google.com/group/mpir-devel?hl=en. > > >>>> > > -- > >>>> > > You received this message because you are subscribed to the Google > >>>> > > Groups > >>>> > > "mpir-devel" group. > >>>> > > To post to this group, send email to [email protected]. > >>>> > > To unsubscribe from this group, send email to > >>>> > > [email protected]. > >>>> > > For more options, visit this group at > >>>> > >http://groups.google.com/group/mpir-devel?hl=en. > > >>>> Nice work Jason! > > >>>> The build will only work on Visual Studio 2008 because some of the > >>>> paths in your baatch files are specific to VS 2008 (e,g. > >>>> VS90COMNTOOLS). > > >>>> As far as I can see you are not setting up the compiler environment, > >>>> which means that it cannot find my compiler on VS 2010. > > >>>> ------------------ > >>>> Yeah , I wasn't sure what the paths were to set up , isn't VS2010 path > >>>> the > >>>> same but with VS100COMNTOOLS instead? > >>>> --------------- > > >>>> But I am impressed with how far you have got! > > >>>> Brian > > >>>> -- > >>>> You received this message because you are subscribed to the Google > >>>> Groups > >>>> "mpir-devel" group. > >>>> To post to this group, send email to [email protected]. > >>>> To unsubscribe from this group, send email to > >>>> [email protected]. > >>>> For more options, visit this group > >>>> athttp://groups.google.com/group/mpir-devel?hl=en. > > >>> With 'comspec' as the location of the Winndows DOS shell (%SystemRoot% > >>> \system32\cmd.exe), the three environemnts on my system are: > > >>> Visual Studio x64 Win64 Command Prompt (2010): > >>> %comspec% /k ""C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC > >>> \vcvarsall.bat"" amd64 > > >>> Visual Studio x64 Cross Tools Command Prompt (2010): > >>> %comspec% /k ""C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC > >>> \vcvarsall.bat"" x86_amd64 > > >>> Visual Studio Command Prompt (2010): > >>> %comspec% /k ""C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC > >>> \vcvarsall.bat"" x86 > > >>> These are (-> is 'targetting'): > > >>> x64 -> x64 > >>> x64 -> x86 > >>> x86 -> x86 > > >>> -- > >>> You received this message because you are subscribed to the Google Groups > >>> "mpir-devel" group. > >>> To post to this group, send email to [email protected]. > >>> To unsubscribe from this group, send email to > >>> [email protected]. > >>> For more options, visit this group at > >>>http://groups.google.com/group/mpir-devel?hl=en. > > >>> -- > >>> You received this message because you are subscribed to the Google Groups > >>> "mpir-devel" group. > >>> To post to this group, send email to [email protected]. > >>> To unsubscribe from this group, send email to > >>> [email protected]. > > ... > > read more »- Hide quoted text - > > - Show quoted text - -- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
