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
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
