On Thursday 28 April 2011 11:46:02 Jason wrote: > 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) >
No , we can't do that , the source dir maybe read only or being shared with other builds , exactly like I do for skynet > 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.
