On 25/07/2013 19:47, Alan Livingston wrote:
> I'm building MPIR to support PyCrypto, and I came across two problems and I
> have solutions:
>
> 1. Many "The process cannot access the file because it is being used by
> another
> process." errors.
>
> The best solution is to add a dependency for each project in the
> solution so that the builds occur in order. This has the same effect as
> setting the maximum number of parallel builds to 1, but it this solution
> constrains the build process no matter what setting is used for the max
> parallel builds.
>
> For example, my solution has the following projects, and I set the
> following dependencies:
> dll_mpir_core2 depends on
> dll_mpir_gc, which depends on
> dll_mpir_k8, which depends on
> dll_mpir_nehalem, which depends on
> dll_mpir_petium4_sse2, which depends on
> lib_mpir_core2, which depends on
> lib_mpir_cxx, which depends on
> lib_mpir_gc, which depends on
> lib_mpir_k8, which depends on
> lib_mpir_nehalem, which depends on
> lib_mpir_pentium4_sse2, which has no dependency.
>
> Then, lib_mpir_pentium_sse2 will be built first, and proceed bottom up
> through the previous list ending with dll_mpir_core2. If specific builds are
> not added to a specific solution's build in the configuration manager, the
> build still succeeds, since there aren't really any dependencies other than
> the pre-build step.
> A complete solution will require some work for the python config tool,
> mpir_config.py, to properly add dependencies to the new projectwhich I have
> not looked at.
Hi Alan,
You are building multiple configurations in parallel, which is very
different to the current philosophy of the Visual Studio build. The
current design is 'select the architecture for which you want to build
and then build it'.
It is certainly possible that mpir_config.py could be modified to
support the build approach you are using but it would probably be better
to supply this as another version of the file rather than attempting to
support both build styles from one build generator (mpir_config.py is
complex enough already!).
It would also add another layer to the maintenance task since there are
a large number of different builds that would have to be placed into
such a hierarchy.
> 2. mpir.h is not generated correctly. Exclamation marks are deleted.
>
> Exclamation marks are used to specify delayed expansion in variables
> under the Win32 command parser. Delayed expansion can be disabled and
> enabled as needed. I have added a command to disable delayed expansion after
> the first line, @echo off, in gen_mpir_h.bat and tested successfully:
>
> @echo off
> setlocal DisableDelayedExpansion
> echo creating mpir.h for %1
I don't understand this one as I wasn't aware that we use delayed
variable expansion anywhere in generating mpir.h - gen_mpir_h.bat is one
of my files and I certainly didn't intend to use any !VAR! variables
when I created it.
In which files are the exclamation marks that are being deleted?
best regards,
Brian
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/groups/opt_out.
