On Mar 1, 5:00 pm, Bill Hart <goodwillh...@googlemail.com> wrote:
> Oh, I forgot about that.
>
> Alright, so I've just confused myself. Forget what I said.
>
> So we should use mpir.h and mpirxx.h and provide scripts which yield a
> gmp.h and gmpxx.h for the user if they so desire. In the case of
> Windows I presume it is possible to do this by just renaming the files
> or making copies with the alternate name. In linux we can choose to
> either rename or provide symlinks.
>
> Is there a performance hit from using symlinks anyone?
>
> Bill.
>
> 2009/3/1 Cactus <rieman...@googlemail.com>:
>
>
>
> > On Mar 1, 4:46 pm, Bill Hart <goodwillh...@googlemail.com> wrote:
> >> It doesn't make sense to provide mpir.h. If we did that, then none of
> >> the projects which use GMP would compile unmodified against mpir. The
> >> same goes for mpirxx.h.
>
> >> Later we might like to include an mpir.h which *only* includes
> >> functions available in mpir but not gmp. But let's make that decision
> >> when we start exposing new functions to the user.
>
> >> I'm not sure if I am actually answering any of the questions you
> >> asked, and I'm not enough of an expert with Windows to answer the
> >> questions about the binaries. Although I have written some medium
> >> sized projects in Windows, they are all self contained. I suppose I
> >> did link against sdl for one of those projects, but it stopped working
> >> every time a new version of the compiler was released (not an MS
> >> compiler) or a new version of sdl was released. So I gave up and
> >> stopped maintaining that project.
>
> >> Bill.
>
> >> 2009/3/1 Cactus <rieman...@googlemail.com>:
>
> >> > I have raised this before but since i has been raised agin, I thought
> >> > we should reflect on it. I will give a WIndows perspective and leave
> >> > someone else to comment on GCC.
>
> >> > Include files
> >> > ========
>
> >> > I have been assuming that include files are easy - but maybe not.
> >> > Windows does not build from within the configure system but starts
> >> > all its operations from gmp-h.in. This file is modified by adding
> >> > Windows specific inserts and the result is copied to mpir.h and gmp.h,
> >> > which are identical. Right now I don't do anything about the C++
> >> > header since I am waiting for a decision on whether we wnat gmpxx.h,
> >> > mpirxx.h or both.
>
> >> > Note that I start from gmp-h.in, NOT mpir-h.in.
>
> >> > All I need for Windows is a clear source from which to build the
> >> > header files and a decision on which header files we will provide.
>
> >> > Binaries
> >> > ======
>
> >> > On WIndows there are a large number of builds - far too many to easily
> >> > accommodate. The variations that are involved are:
>
> >> > 1. static library | DLL
> >> > 2. release | debug
> >> > 3. With or without MP support
> >> > 4. MSVC Library Linking (static, dynamic, release or debug)
>
> >> > Some people want binary names that encapsulate all these choices but I
> >> > have not been able to find an easy way of doing this. So I don't
> >> > capture any of this in the names I use:
>
> >> > static libraries: mpir.lib (exe) and mpir.pdb (symbols)
> >> > DLLs: mpir.dll (dll), mpir.pdb (symbols), mpir.exp (exports) and
> >> > mpir.lib (stub library)
>
> >> > Having the same name for the static library and the DLL stub library
> >> > makes it easy to use either in applications.
>
> >> > Brian
>
> > I'm confusd now - if we don't use mpir.h, why have we gone to the
> > trouble of renaimg gmp.h to mpir.h in all the MPIR source files?
>
> > Brian
On Windows I just generate both gmp.h and mpir.h from gmp-h.in.
But I don't generate mpirxx.h from gmpxx.h at the moment. Its easy to
do once we decide on naming.
Jeff wanted the same names on Windows and Linux but I am not sure this
matters since the name extensions .lib and .a are different anyway.
And I don't much like libmpir.lib on WIndows because I already know
its a library from the extension so mpfr.lib is sufficient.
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
-~----------~----~----~----~------~----~------~--~---
