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). > > 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
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.