Possible Issue with the Windows command lIne build?

[Cactus]

As far as I can tell, the Windows command line build relies on a file (cfg.h) in each of the mpn assembler directories. This file holds a list of the assembler files in the directory 

But there is a potential problem here because these cfg.h files are built only when the Visual Studio build for each architecture is generated. In consequence a command line build for an architecture will only work after the Visual Studio build is generated for this architecture.   This is a potential problem since it will be faar from obvious for those who use the command line build that they have to run the Visual Studio build generator for the architecture in question before they run the command line build.

There are several ways of handling this.  The first is to document the need to run the Visual Studio build generator before running a Windows command line build.  The second is to modify the Visual Studio build generator  so that it can be called from the command line build process and hence generate the needed cfg.h file.  The third is to generate and  add all the needed cfg.h files to the MPIR repository and MPIR distributions.  

The first of these is simple but unlikely to work well as many users don't pay much attention to the documentation. The third is painful as it will be an ongoing maintenance nightmare.  Which leaves the second option, one which will require quite a bit of work by me and by Jason or Case.  This will also mean that the command line build will end up with a Python dependency (assuming that we can run  Python from the command line build script).

    Brian

[Case Van Horsen]

I'll take a look at this over the weekend.

Case
>
> Brian
>
> --
> You received this message because you are subscribed to the Google Groups
> "mpir-devel" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/mpir-devel/-/7CV3fPZGk5QJ.
> To post to this group, send email to mpir-...@googlegroups.com.
> To unsubscribe from this group, send email to
> mpir-devel+...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/mpir-devel?hl=en.

[Bill Hart]

I don't know very much about the command line build. But I am not
really in favour of option 1.

I don't see why option 3 is a problem. However, it depends. Is the cfg
file different per architecture? Would it automatically find the right
one if they were all there in their respective directories?

Bill.

[Bill Hart]

Oh wait, I think option 3 may be a problem. If we distribute the .cfg
files, we also need to distribute a GPL means of generating them. So I
think option 2 is the only possibility, if I am not mistaken.

[Brian Gladman]

-----Original Message-----
From: Bill Hart
Sent: Friday, September 28, 2012 4:16 PM
To: mpir-...@googlegroups.com
Subject: Re: [mpir-devel] Possible Issue with the Windows command lIne
build?

I don't know very much about the command line build. But I am not
really in favour of option 1.

I don't see why option 3 is a problem. However, it depends. Is the cfg
file different per architecture? Would it automatically find the right
one if they were all there in their respective directories?

====================

The problem is just the overhead of producing them and keeping them up to
date.

They are generated automatically by the Visual Studio build generator so
someone has to build every possible architecture variation to set up all of
them.

The Visual Studio build in MPIR is now very different to that supplied
earlier. Apart from a small number of pre-configured builds, a user now has
to run a Python program and select the architecture for which they wish to
build. This then produces a number of files needed for building with Visual
Studio, after which MPIR for the selected architecture can be built using
the Visual Studio IDE. The necessary cfg.h files are built as a part of
this process.

I can do this and add them if we want to adopt this solution but it means in
effect that I end up partly supporting the command line build, a task that I
am not really keen to take on. However, I can do it as a 'one off'
provided I am not then committed to provide on-going support for it.

Brian

[Brian Gladman]

-----Original Message-----
From: Bill Hart
Sent: Friday, September 28, 2012 4:18 PM
To: mpir-...@googlegroups.com
Subject: Re: [mpir-devel] Possible Issue with the Windows command lIne
build?

Oh wait, I think option 3 may be a problem. If we distribute the .cfg
files, we also need to distribute a GPL means of generating them. So I
think option 2 is the only possibility, if I am not mistaken.

======================

No, we do provide a way of generating them - the Python program called
mpir_config.py that is a part of the MPIR distribution.

Brian

[Bill Hart]

On 28 September 2012 16:36, Brian Gladman <b...@gladman.plus.com> wrote:
> -----Original Message----- From: Bill Hart
> Sent: Friday, September 28, 2012 4:16 PM
> To: mpir-...@googlegroups.com
> Subject: Re: [mpir-devel] Possible Issue with the Windows command lIne
> build?
>
>
> I don't know very much about the command line build. But I am not
> really in favour of option 1.
>
> I don't see why option 3 is a problem. However, it depends. Is the cfg
> file different per architecture? Would it automatically find the right
> one if they were all there in their respective directories?
>
> ====================
>
> The problem is just the overhead of producing them and keeping them up to
> date.
>
> They are generated automatically by the Visual Studio build generator so
> someone has to build every possible architecture variation to set up all of
> them.
>
> The Visual Studio build in MPIR is now very different to that supplied
> earlier. Apart from a small number of pre-configured builds, a user now has
> to run a Python program and select the architecture for which they wish to
> build. This then produces a number of files needed for building with Visual
> Studio, after which MPIR for the selected architecture can be built using
> the Visual Studio IDE. The necessary cfg.h files are built as a part of
> this process.

I see.

>
> I can do this and add them if we want to adopt this solution but it means in
> effect that I end up partly supporting the command line build, a task that I
> am not really keen to take on. However, I can do it as a 'one off'
> provided I am not then committed to provide on-going support for it.

You'll have to give me a list of all the .cfg files, as I will have to
add them to the distribution mechanism, otherwise they won't be in the
release tarball.

It is possible to construct a script which generates them all in one go?

Bill.

>
>
> Brian
>
> --
> You received this message because you are subscribed to the Google Groups
> "mpir-devel" group.

[Bill Hart]

I am trying to fix a compiler warning on MinGW32, but I don't
understand the code, so I don't know the correct fix.

It is complaining that there is an overflow in the expressions:

-INTMAX_MIN & GMP_NUMB_MASK, -INTMAX_MIN >> GMP_NUMB_BITS

on line 60 of the test program t-set_sx.c.

I don't know what the INTMAX_MIN macro does.

Presumably GMP_NUMB_MASK is 32 bits, but I am not sure if INTMAX_MIN
may be 64 bits, as it is long long. Not too sure.

Does anyone have any clues?

Bill.

[Brian Gladman]

===========================

Yes, that's a good idea. I think I can probably do this by stripping out
stuff from my normal build generator (it will be a Python script though).

If we do this, all directories (and subdirectories) in mpn/x86w and
mpn/x86_64w will end up with a cfg.h file in them. Listing these
directories is I hope easier than me compiling a list :-)

Brian

[Bill Hart]

The problem is the expression:

-INTMAX_MIN

The expression

INTMAX_MIN

is fine.

Bill.

[Bill Hart]

Indeed on MinGW32 INTMAX_MIN is 64 bits and GMP_NUMB_BITS is 32 bits.

However, INTMAX_MIN is the minimum negative long long, of which you
cannot take the unary minus, since it has no positive counterpart.

Could someone who understands the code please advise me on what I
should do to fix it.

It's the last bug left of which I am aware.

Bill.

[Brian Gladman]

===========================

Its such a good idea that I have already done it!

In the big gap in MPIR development progress, I had completely forgotten
about solving this problem over a year ago.

So all that has to happen is that anyone building the command line build has
to run mpir_config.py only once and all the cfg.h files are generated.

So we can either (a) add all these files to distributions, (b) document the
need to run mpir_config.py once before any Windows command line build, or
(c) run a slightly modified mpir_config.py from the command line build
script.

Brian










already generate all the cfg.h files

If we do this, all directories (and subdirectories) in mpn/x86w and
mpn/x86_64w will end up with a cfg.h file in them. Listing these
directories is I hope easier than me compiling a list :-)

Brian

[Bill Hart]

I now like either b or c. But I'll leave it up to you to decide. Of
course the other option is to test for the existence of a cfg file. If
none is found, report to the user that they must first run
mpir_config.py and abort. We can then document this.

Bill.

[Brian Gladman]

-----Original Message-----
From: Bill Hart
Sent: Friday, September 28, 2012 5:42 PM
To: mpir-...@googlegroups.com
Subject: Re: [mpir-devel] Possible Issue with the Windows command lIne
build?

[snip]

> Its such a good idea that I have already done it!
>
> In the big gap in MPIR development progress, I had completely forgotten
> about solving this problem over a year ago.
>
> So all that has to happen is that anyone building the command line build
> has
> to run mpir_config.py only once and all the cfg.h files are generated.
>
> So we can either (a) add all these files to distributions, (b) document
> the
> need to run mpir_config.py once before any Windows command line build, or
> (c) run a slightly modified mpir_config.py from the command line build
> script.
>

I now like either b or c. But I'll leave it up to you to decide. Of
course the other option is to test for the existence of a cfg file. If
none is found, report to the user that they must first run
mpir_config.py and abort. We can then document this.

==============================

I have now made the changes to the Windows command line build to generate
all the cfg.h files.

This means that the this build will now fail when Python is not installed.

If we don't like this we will have to go back to the previous make.bat file
and arrange for one of the other solutions.

Case, can you please check that the command line build is still OK for you?

Brian