Yes, I think mpir.lib is fine. So +1 for that. Now I'll butt out of the discussion about Windows naming discussion and let you and Jeff decide what you want.
Bill. 2009/3/1 Cactus <rieman...@googlemail.com>: > > > > 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 -~----------~----~----~----~------~----~------~--~---
