On Saturday 14 August 2010 10:03:09 Cactus wrote: > On Aug 14, 9:00 am, Cactus <rieman...@gmail.com> wrote: > > On Aug 14, 4:02 am, "jason" <ja...@njkfrudils.plus.com> wrote: > > > Hi Brian > > > > > > I notice that for win64 you have a scipt gen_mpir_h.bat which define's > > > LONG_LONG_LIMB 1 > > > > > > Is there any reason you did it this way , rather than at somewhere > > > before line194 in gmp-h.in > > > #ifdef _WIN64 > > > #define _LONG_LONG_LIMB 1 > > > #endif > > > > > > because for the mingw64 I need to set it anyway. > > > > There are several reasons for this, one being a desire to be able to > > define what I need on Windows without changing files in the MPIR > > distribution. This is partly historical and comes from my GMP build > > at a time when I could not expect TG to allow any Windows changes into > > gmp_h.in. > > > > The second, more important, reason is that this aligns with the > > intended pre-processing of gmp-h.in, which includes @symbol@ values > > that are intended for substitution when gmp-h.in is used to build to > > build gmp.h or mpir.h. I have to either remove or substitute all > > these @symbol@ values so it is natural to do the definitions during > > this process (whiich I assume parallels what happens in the Unix/Linux > > builds). > >
pretty much > > But it turns out that the are significant benefits for the Visual > > Studio IDE, that can be much faster when such conditionals are not > > present because its intellisense database, which enables code and > > symbol browsing in the IDE, background compiles both code paths for > > conditionals in order to create its database (this is not quite what > > it does but it would be hard to explain the full story of how it > > avoids the combinatorial explosion in code paths). > > > > But if you need it in gmp-h.in, I think my script will still work > > provided all the associated @symbol@ elements in gmp-h.in are removed. > > > > Brian > There is another place it is used. When running configure (This is before we know how to fill all these @symbols@) , the configure script compiles a short c prog to test the size of a mp_limb_t ie output from configure (linux 64bit) checking for assembler byte directive... .byte checking how to define a 32-bit word... .long checking if .align assembly directive is logarithmic... no checking if the .align directive accepts an 0x90 fill in .text... yes checking size of unsigned short... 2 checking size of unsigned... 4 checking size of unsigned long... 8 checking size of mp_limb_t... 8 ####################### creating config.m4 configure: creating ./config.status config.status: creating Makefile config.status: creating mpf/Makefile I not sure it is strictly necessary , but for the mo we need it . As I rip autotools to bits , it may not survive. Todo this is sets the define __GMP_WITHIN_CONFIGURE and just includes gmp-h.in So I can guard it with the above define , which is not set by MSVC . Although I may need to set it again for the build , I'll have to try it to find out. > In fact, provided your definition occurs before line 60 (I think), all > my script will do is to add a redundant define since it is guarded. > > If you wish to add it later, all it needs is a guard to avoid multiple > definitions. > > But I assume that the Unix/Linux builds have to process gmp-h.in to > produce mpir.h including the relevant substitutions --- shouldn't the > mingw64 build do the same? > > Brian -- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to mpir-de...@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.
