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