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.
