flint-2.3 beta3

[Bill Hart]

A third beta has been uploaded. This fixes:

* some gcc's complain about the order of command line arguments -- yeah really

Bill.

[Bill Hart]

We decided that flint-2.3 is to be considered in beta release for the
time being (this was always the intention, however, for some odd
reason, when Fredrik and I crafted the release announcement, both of
us forgot to mention it. It was mentioned on the webpage though).

Either way, I think it won't be beta for much longer.

We still have to decide an appropriate strategy for Cygwin, whose gcc
is so broken that some of the tests fail. And we obviously want to
sort through the matrix issue you mentioned off list (I'm looking at
that now). But otherwise, people are reporting things are working, so
we can make the release final very soon. We'll then do minor releases,
2.3.1, 2.3.2, etc., if any further issues arise.

Bill.

On 10 July 2012 17:19, John Cremona <john.c...@gmail.com> wrote:
> Correct me if I am wrong, but since 2.3 has already been released, should
> not this be a beta of 2.4? Or do you count backwards in Australia?
>
> John

[Jean-Pierre Flori]

I'm currently (painfully) building Sage on cygwin, struggling with Python 2.7 at the moment.
When this is done, I'll finalize my changes for the Cygwin  build of FLINT, it would be great if you could wait for that before releasing the final release of 2.3.
It sould be more than a couple of days on my side.

Best,

[Bill Hart]

Sure, we will definitely wait for your final changes for Cygwin. I
also plan to run the test suite on my Cygwin setup once again to
confirm that nothing fails that I didn't expect to fail. But I'll wait
for your changes before doing that.

There's a couple of things Fredrik will want to do for the final
version (including a bug fix in nmod_mat_rref) and a (short) new
chapter to be added to the docs by me. A couple of days should be
fine, though Fredrik is actually at a conference this week, and I
don't know if he has web access or not.

I'd also like the final beta to stay up for a couple of days before
making it final. Perhaps by the weekend we can finalise it.

Bill.

[Jean-Pierre Flori]

Hi all,

Sorry for the delay, but I've finally pushed two commits to tweak the build system.

I've let the shared library end with dylib64 on Darwin 64 bits, not sure this is a good idea, but it used to be so in flint 1.*.
I could not test it on such hardware, so if someone could check that the code actually works, that would be great.
I could test it on Linux 64 bits and Cygwin where everything seems fine.
The building commands on Cygwin could be modified to build a more prpoer library with .dll/.dll.a stuffs by passing the correct flags to gcc/ld as is done by libtool for MPIR/MPFR et al, but that's not needed to have something useable.

As far as enabling or disabling shared/static libraries, i've removed the piece of code preventing the build of a shared library on Cygwin/Mingw.
As far as I can tell, this is possible on Cygwin, and I guess should be on Mingw.
There is no detection, of what versions of MPIR/MPFR/NTL are installed, but I guess it's better to let the user do what he wants rather that put arbitrary limitations.
Anyway, if you really want to test these kind of things, IMHO the only relevant thing to do is to prevent the build of a static library if any of the above is only available as shared (although some hackish tricks could make it possible to build such a strange library).

I've modified the hash bang line of the configure script to use bash.
IIRC Bill mentioned at some point that bash was needed anyway.
The reason why I want to make it explicit is that I want to use "echo -e" to print CONFIG_DEFINES in config.h.
Indeed, the -e flag is needed to let the "\n" be interpreted with bash, whereas (da?)sh does not need the -e flag and actually print it verbatim when it is passed.
And on Cygwin, bash is called by default, so that the \n are printed as such in config.h which make "make" fail.

I've also quite modified the dependencies between the different make targets and add some magic to disable -fPIC on Cygwin.

If noone objects, it would also be great to have only one copy of the build_dirs Makefile that would be copied everywhere by the configure script.
Moreover, that would definitely simplify the process of modifying it and this change can be reverted in the future if this is needed.

Best,
JP

[Bill Hart]

On 19 July 2012 01:17, Jean-Pierre Flori <jpf...@gmail.com> wrote:
> Hi all,
>
> Sorry for the delay, but I've finally pushed two commits to tweak the build
> system.
>
> I've let the shared library end with dylib64 on Darwin 64 bits, not sure
> this is a good idea, but it used to be so in flint 1.*.
> I could not test it on such hardware, so if someone could check that the
> code actually works, that would be great.
> I could test it on Linux 64 bits and Cygwin where everything seems fine.
> The building commands on Cygwin could be modified to build a more prpoer
> library with .dll/.dll.a stuffs by passing the correct flags to gcc/ld as is
> done by libtool for MPIR/MPFR et al, but that's not needed to have something
> useable.
>
> As far as enabling or disabling shared/static libraries, i've removed the
> piece of code preventing the build of a shared library on Cygwin/Mingw.
> As far as I can tell, this is possible on Cygwin, and I guess should be on
> Mingw.

I'll try it on my system. It didn't work before. But that may have
been due to the -fPIC.

> There is no detection, of what versions of MPIR/MPFR/NTL are installed, but
> I guess it's better to let the user do what he wants rather that put
> arbitrary limitations.
> Anyway, if you really want to test these kind of things, IMHO the only
> relevant thing to do is to prevent the build of a static library if any of
> the above is only available as shared (although some hackish tricks could
> make it possible to build such a strange library).

Ok.

>
> I've modified the hash bang line of the configure script to use bash.
> IIRC Bill mentioned at some point that bash was needed anyway.
> The reason why I want to make it explicit is that I want to use "echo -e" to
> print CONFIG_DEFINES in config.h.
> Indeed, the -e flag is needed to let the "\n" be interpreted with bash,
> whereas (da?)sh does not need the -e flag and actually print it verbatim
> when it is passed.
> And on Cygwin, bash is called by default, so that the \n are printed as such
> in config.h which make "make" fail.

Unless I am mistaken, bash is available on gnu systems only and
therefore we can't use it. You'll find for example that GNU extensions
do not work on some of the GCC build farm computers.

>
> I've also quite modified the dependencies between the different make targets
> and add some magic to disable -fPIC on Cygwin.

Why did the make targets need to be changed? I'm really, really
reluctant to merge changes to these without a very specific reason.

>
> If noone objects, it would also be great to have only one copy of the
> build_dirs Makefile that would be copied everywhere by the configure script.
> Moreover, that would definitely simplify the process of modifying it and
> this change can be reverted in the future if this is needed.
>

Agreed. But let's do that for the next release. We should be making
very conservative changes at this point.

Bill.

[Jean-Pierre Flori]

I'll try it on my system. It didn't work before. But that may have
been due to the -fPIC.

I'll try to install Mingw64 tonight, but Im short on time.

Unless I am mistaken, bash is available on gnu systems only and
therefore we can't use it. You'll find for example that GNU extensions
do not work on some of the GCC build farm computers.

That's unfortunate.
So one should explicitely test what  `echo "\n"` and `echo -e "\n"` output to get something portable.
The main problem is that on my quite default Cygwin install, /bin/sh points to bash and echo "\n" prints \n rather than a linebreak.
Another solution would be to directly encode linebreaks in CONFIG_DEFINES so that "echo" alone is enough.

>
> I've also quite modified the dependencies between the different make targets
> and add some magic to disable -fPIC on Cygwin.

Because I was not really convinced with the current way it was organized, but that's only my point of view and that's your code :)
Anyway, I mostly "reorganized" and "refactored" things within the targets, rather than "modified" them, especially to better divide the shared and static targets.
Feel free to have a look, but I guess that even if you find some interesting ideas it could only get in a future release.

Agreed. But let's do that for the next release. We should be making
very conservative changes at this point.

Good point. 

[Bill Hart]

On 19 July 2012 02:08, Jean-Pierre Flori <jpf...@gmail.com> wrote:
>
>> I'll try it on my system. It didn't work before. But that may have
>> been due to the -fPIC.
>>
> I'll try to install Mingw64 tonight, but Im short on time.
>
>> Unless I am mistaken, bash is available on gnu systems only and
>> therefore we can't use it. You'll find for example that GNU extensions
>> do not work on some of the GCC build farm computers.
>
> That's unfortunate.
> So one should explicitely test what `echo "\n"` and `echo -e "\n"` output
> to get something portable.
> The main problem is that on my quite default Cygwin install, /bin/sh points
> to bash and echo "\n" prints \n rather than a linebreak.
> Another solution would be to directly encode linebreaks in CONFIG_DEFINES so
> that "echo" alone is enough.

I would break the config_defines up into individual flags and echo
them out one at a time as we do for the Makefile. I tried multiple
combinations of putting "\n" in a single string in configure and none
of them worked on all systems I tried.

>>
>> >
>> > I've also quite modified the dependencies between the different make
>> > targets
>> > and add some magic to disable -fPIC on Cygwin.
>>
> Because I was not really convinced with the current way it was organized,
> but that's only my point of view and that's your code :)
> Anyway, I mostly "reorganized" and "refactored" things within the targets,
> rather than "modified" them, especially to better divide the shared and
> static targets.
> Feel free to have a look, but I guess that even if you find some interesting
> ideas it could only get in a future release.

I would prefer not to change this for the current release, as we have
something that works. Unless it is broken, we shouldn't fix it. Of
course next release we'll go through another whole testing cycle and
it will be fine to make less conservative changes.

>>
>>
>>
>> Agreed. But let's do that for the next release. We should be making
>> very conservative changes at this point.
>>
> Good point.

Bill.

[leif]

On 19 Jul., 02:17, Jean-Pierre Flori <jpfl...@gmail.com> wrote:
> I've modified the hash bang line of the configure script to use bash.
> IIRC Bill mentioned at some point that bash was needed anyway.
> The reason why I want to make it explicit is that I want to use "echo -e"
> to print CONFIG_DEFINES in config.h.
> Indeed, the -e flag is needed to let the "\n" be interpreted with bash,
> whereas (da?)sh does not need the -e flag and actually print it verbatim
> when it is passed.
> And on Cygwin, bash is called by default, so that the \n are printed as
> such in config.h which make "make" fail.

You should probably test the behaviour of 'echo' (a built-in function
or e.g. '/bin/echo') and define a macro (e.g. ECHO_E).

FWIW,

$ echo '\n' | wc -l

yields either 1 or 2 (the latter if '\n' is interpreted);

$ echo -e | wc -w

either 0 or 1 (the latter if '-e' is *not* interpreted as an option by
'echo').


As an alternative, you could of course use 'cat' (and "here"
documents) instead... ;-)


-leif