On Apr 12, 11:05 pm, Bill Hart <goodwillh...@googlemail.com> wrote: > On 12 April 2010 21:04, Antony Vennard <antony.venn...@gmail.com> wrote: > > > Yes. > > > Can we manage it with git? Is there a git repo already...? > > There's no git repo yet. But yes, we have to manage it with git. svn > is too limiting. > > But we'd need to give very careful thought to how we do Windows > support (git doesn't work very well on Windows GUI). > > > Can I write #pragma omp declarations all over it? I.e. can I start > > parallelising things early on? > > This conflicts with one of your goals below. The only compilers which > support OpenMP that I am aware of are the Intel compiler and GCC > basically. Probably MSVC supports pthreads, not sure about OpenMP.
MSVC has good support for OpenMP so this is not a problem. I don't see OpenMP mentioned for PCC though. Digital Mars cannot produce x64 code on Windows but that would not be problem as we would not need to support all compilers on all platforms. > > I'll license all contributions on MPIR as > > BSD which is easily compatible with LGPLv3 then I'm good, really, > > providing I don't duplicate any existing MPIR work. I shall be very > > careful not to. > > Can we make it build under various compilers i.e. pcc, gcc, icc, cl, > > digital mars c etc? > > I think it is terribly important to target pcc and gcc, as you will > get a lot more interest from BSD devels if you do that. I've never > used icc personally, but I will be buying a copy some time soonish. So > long as it does most of what gcc does, I don't see why not. I don't > know anything about the others. I won't be buying copies. ICC is worth supporting as its a first rate compiler and is multi- platform (both Linux and Windows). > The main aim has got to be to get something working within 6-12 > months. That means really restricting our goals. And that means not > getting distracted with unimportant laundry lists of goals. Usually > you find that if someone has an interest in doing something, they'll > pop up and offer to do it. Just take them up on it when it happens, so > long as it doesn't slow the whole project down. > > Can we get something working in 6-12 months. Yes we can, if we choose > our goals carefully. > > > Obviously we might have to duplicate effort > > sometimes, but one of my feelings for gnu software is that it can only > > be compiled by gcc and I don't like that, or more specifically I don't > > like being tied to one way of working should I want to change. > > Can we not use the GNU coding style? The only reason for suggesting this > > is I don't like it, there's no actual technical merit to it. I prefer > > things with lots of braces in, 4-space tab width, functions all on one > > line... you'll see when I start committing. > > Everyone has their preferred coding style. We'd have to agree on one, > and it should be clear and readable. There are good reasons for imposing some aspects of style as an aid to build automation. But I would be against imposing styles in some areas such as brace placement, where people have strong preferences. > > What's it gonna be called? > > I don't really care. So far I've had it called mpzz, libnt, mpir-bsd, > flint3 and probably other things. I got sick of all of these pretty > quick. > > I've already had far more off list interest in this idea than anything > else we've floated. I'm leaning more and more towards actually doing > it. > > Anything we come up with that is actually better than MPIR, we can > insert into MPIR (so long as we keep the interface compatible enough), > as BSD licensed code is still compatible with LGPL v3+. 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-de...@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.
