On Thursday 28 April 2011 10:37:23 Cactus wrote: > On Apr 28, 10:09 am, Jason <ja...@njkfrudils.plus.com> wrote: > > On Thursday 28 April 2011 09:04:01 Cactus wrote: > > > On Apr 28, 8:24 am, Cactus <rieman...@gmail.com> wrote: > > > > On Apr 28, 3:37 am, Jason <ja...@njkfrudils.plus.com> wrote: > > > > > On Thursday 28 April 2011 01:29:01 Jason wrote: > > > > > > On Thursday 28 April 2011 00:16:57 Jason wrote: > > > > > > > On Thursday 28 April 2011 00:12:14 Jason wrote: > > > > > > > > Hi > > > > > > > > > > > > > > > > I removed longlong.h from the distro , it is now constructed > > > > > > > > by configure (that was dead easy , used the same bit of code > > > > > > > > as that does gmp-mparam.h , although later on we integrate > > > > > > > > it with the mpn functions and gmp-impl.h) There is just a > > > > > > > > few ifdef to put back in there proper place (ie non-gnu asm > > > > > > > > code etc) , and the windows header will have cope with Mingw > > > > > > > > and MSVC(easy) > > > > > > > > > > > > > > > > Jason > > > > > > > > > > > > > > I'll be removing the -DNO_ASM option , it serves no purpose now > > > > > > > , it's only function what to stop the old longlong.h including > > > > > > > asm code in a generic C build.When you select a generic C > > > > > > > build now the standard path selection will of course not > > > > > > > select any asm code. > > > > > > > > > > > > > > Jason > > > > > > > > > > > > I've put all the proper ifdef's back and done the 64bit windows > > > > > > header and the construction of longlong.h on the MSVC cl build > > > > > > > > > > > > The MSVC build projects will need to construct longlong.h via > > > > > > concatcation of longlong_pre.h arch_specific_longlong.h > > > > > > longlong_post.h > > > > > > > > > > > > see the longlong bit in win/make.bat > > > > > > > > > > > > I have also removed for some arch's some support for gcc version > > > > > > 1 :) > > > > > > > > > > > > We can also remove all this stuff > > > > > > HAVE HOST _CPU_x86 powerpc etc > > > > > > as this can now be taken care off with our standard path > > > > > > selection , although there our a few files which will need some > > > > > > editing first. > > > > > > > > > > > > Jason > > > > > > > > > > One possible problem is that longlong.h is now a built file rather > > > > > than a source file so if you build out of the tree , longlong.h is > > > > > in a different directory , this doesn't affect us , but some > > > > > programs may rely on it , from mpfr however > > > > > > > > > > Building MPFR with internal GMP header files > > > > > ============================================ > > > > > > > > > > MPFR built with internal GMP header files is a bit faster, so you > > > > > may want to build it with them. Just do this in step 1: > > > > > > > > > > ./configure --with-gmp-build=GMPBUILD > > > > > > > > > > where GMPBUILD is the GMP build directory. The needed header files > > > > > are: gmp-impl.h, longlong.h and all the necessary headers to use > > > > > them. > > > > > > > > > > As gmp-impl.h and longlong.h are only in the GMP source directory, > > > > > you first need to copy these files to the build directory if it is > > > > > different (there may be other workarounds, such as setting > > > > > $CPPFLAGS to search the GMP source directory). > > > > > > > > > > So we are now in the "right" place , and there nothing to say that > > > > > gmp-impl.h may also become a built file much like gmp.h > > > > > > > > > > I could make the --enable-gmpcompat option also copy it to the > > > > > source dir ? > > > > > > > > > > Jason > > > > > > > > I have a problem with the build now. > > > > > > > > The MSVC compiler first looks for header files in the same directory > > > > as a source code file and then, if this fails, in any specified > > > > header directories. > > > > > > > > As a result all the source code files in 'mpir\mpn\generic\' now > > > > pick up the empty longlong.h file in this directory and not the one > > > > in 'mpir \' as intended. > > > > > > > > The solution id either to rename the longlong.h architecture files to > > > > longlong.inc (or anything other than longlong.h) or change the C > > > > source code files to add a directory path to the longlong.h include > > > > line in each of them. > > > > > > > > I imagine that the former solution is the easiest - should I do this? > > > > > > > > Brian > > > > > > I suggest that we use the names: > > > > > > longlong_pre.h > > > longlong_inc.h > > > longlong_post.h > > > > > > I now have a build based on this change but I have not committed it > > > yet in case this is a problem for other builds. > > > > > > Brian > > > > Yep , that great , commit it and I can change the autotools bits. > > > > I'm still having problems with FAT builds and the incestuous files preinv > > divrem_1 mod_1 and the mess that configure uses to build them :( > > > > Thanks > > Jason > > Ok, I have now done (I hope) all the file name changes and the MSVC > build chaange. > > Brian
Yep , thats great , everything appears to work now , the FAT builds were also getting confused by the copies of longlong.h I'll make sure --enable-gmpcompat makes a copy of longlong.h (although it may have to be at make-install time , like before) I may also start to move some asm bit's in gmp-impl.h into longlong.h , although to be on the safe side , I will only move those functions that depend on longlong.h , so we know the user must of included longlong anyway Thanks Jason -- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
