On Saturday 14 August 2010 19:07:58 Jason wrote: > On Saturday 14 August 2010 18:39:50 Cactus wrote: > > On Aug 14, 4:53 pm, "jason" <ja...@njkfrudils.plus.com> wrote: > > > ----- Original Message ----- > > > From: "jason" <ja...@njkfrudils.plus.com> > > > To: <mpir-devel@googlegroups.com> > > > Sent: Saturday, August 14, 2010 4:43 PM > > > Subject: Re: [mpir-devel] Re: MPIR 2.2 > > > > Hi Jason, > > > > The assembler extension on Windows is 'asm' and changing this would be > > a big issue for me with a high cost. > > > > I would either have to change all my assembler code (much more than > > MPIR) to use the 'as' extension (which would make my code unique on > > Windows since pretty well everyone uses 'asm') or I would have to have > > special build customisation files for MPIR, which would be a high cost > > in maintenance terms. > > > > This is not a path I would want to go down so I suggest that you just > > copy the Windows stuff into separate directories for use in mingw64. > > This would give you the freedom to do what you want without changing > > the Visual Studio builds. > > > > Brian > > OK , I asked in case it was easy. > As we have a pre-distro step (ie autoreconf) every time we add a > file/change configure anyway , I can just add it to that so that the > "user" never need know. > Perhaps even better the sym links that configure makes can just "drop the > m" . But I still HAVE to change the include path , as it is taken from > where the sym link is , not the original file location. In a pre-distro > step I can easily automate it and keep it legible unlike if we did it at > build time , then we have to comply with everything that been done before > on every machine , ever. > > I have to change the object file format for yasm as for some reason it does > not default to x64 , this is easy , and I've got to link to > x86_64w/yasm_mac.inc I think it will work then , it should compile anyway > :) > > Is there much difference between x86w and x86 , they use the same ABI , I > wonder , we could put this into the pre-distro step , it would save > maintainance , and the code base would be notionally smaller >
I say notionally because , our svn is a bit different to most , if you get the svn of yasm or pari for example , then you can not just build it with the usual configure && make , you need to do what I have been calling the "pre- distro" step , ie for yasm you have to run .autogen (which requires autotools) and for pari you need bison and some other things . Their advantage is that only user generated files are in the svn , so it keeps it small. Our advantage is that the typical user can get it and build it just like a release. Our disadvantage is that a lot of machine generated files make the svn bigger and dont truly reflect how simple our code is :) > > Jason -- 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.
