On Feb 5, 8:25 pm, Cactus <rieman...@googlemail.com> wrote:
> On Feb 5, 7:56 pm, ja...@njkfrudils.plus.com wrote:
>
>
>
> > On Wednesday 04 February 2009 19:54:03 Bill Hart wrote:
>
> > > Thanks. As soon as we release, it would be great if you could give it
> > > a go and we can issue a service release.
>
> > Should I create a branch for it?
>
> > I cant do the windows bits , Brian ?
>
> > I dont do C++ , and I dont know how comprehensive the make check c++ bit is
> > ,
> > if someone can email me some c++ programs , I can test them
>
> > I can leave or delete the old directory mpbsd ?
>
> > I assume we are going to leave internal names as __gmp_blah etc
>
> > > Bill.
>
> > > 2009/2/4 <ja...@njkfrudils.plus.com>:
> > > > On Wednesday 04 February 2009 18:35:24 Bill Hart wrote:
> > > >> Hi Mariah,
>
> > > >> 2009/2/4 Mariah <mariah.le...@gmail.com>:
> > > >> > Bill,
>
> > > >> > On Feb 4, 12:25 am, Bill Hart <goodwillh...@googlemail.com> wrote:
> > > >> >> I have placed a tarball here:
>
> > > >> >>http://sage.math.washington.edu/home/wbhart/mpir-0.9.0.tar.gz
>
> > > >> > Some quick observations -
>
> > > >> > 1. It looks like you have to build in the source tree. Many software
> > > >> > packages let you have an object directory separate from the source
> > > >> > directory. This is useful for networks with lots of different
> > > >> > architectures hanging on them. You only need one copy of the source
> > > >> > file.
>
> > > >> Autotools is supposed to let you do that as standard. We may have
> > > >> broken something which allows that, or perhaps it was never possible
> > > >> with GMP. I don't know. I'll add a trac ticket and we can look at
> > > >> this.
>
> > > >> > 2. The built include and library files are gmp.h, libgmp.a, etc.
> > > >> > Shouldn't they be mpir.h, libmpir.a? Leaving the names as gmp.h,
> > > >> > libgmp.a may discourage system dministrators from overwriting the
> > > >> > system gmp.h, libgmp.a from GNU gmp. I can see that you may need an
> > > >> > option for symbolic links (gmp.h -> mpir.h, etc) for legacy software
> > > >> > that expects (gmp.h, libgmp.a). But surely you want to encourage
> > > >> > projects to transition to MPIR (and not remain with GMP).
>
> > > >> We have decided not to do this for MPIR-0.9.0.
>
> > > >> Actually, none of us know how to do it aanyway! Perhaps either you or
> > > >> Michael can help with this. I looked into it and didn't even know
> > > >> where to start. We do have a trac ticket for it.
>
> > > >> Bill.
>
> > > > I know how to do this , mostly.
>
> > > > Jason
>
> At the moment I use gmp.h during the windows build phase and then copy
> this to both a gmp.h and an mpir.h include file after the build.
>
> In terms of the names I am using, these are: mpir.h (C header),
> mpirxx.h (C++ header), mpir.dll (DLL), mpir.exp (export library),
> mpir.lib (static library and DLL stub library) and mpir.pdb (symbol
> database).
>
> I don't vary these names so debug / release, win32 / x64, DLL / Static
> CRT, and all the various assembler enhanced versions all end up with
> exactly the same names.
>
> Provided I know what things need to have new names and what don't I
> can quite easily add to or change any of the above.
>
> Brian
Oops, I also forgot about the C++ bits: the DLLs have both the C and
the C++ libraries. The C++ libraries are mpirxx.lib and mpirxx.pdb.
I should mention that we have an inconsistency in the imminent release
since I am already using these mpir names in the Windows build.
Does this matter?
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-devel@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
-~----------~----~----~----~------~----~------~--~---
