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