It's worth changing the documentation for this too (in the doc/devel directory I think, in the file configuration or something like that). That's the one I refer to when adding files to MPIR, so it should be kept up-to-date.
Bill. On 13 August 2010 16:15, Jason <ja...@njkfrudils.plus.com> wrote: > Hi > > I changed the files > pre_divrem_1.* to preinv_divrem_1.* > pre_mod_1.* to preinv_mod_1.* > mode1o.* to modexact_1c_odd.* > > and removed the autotools bumf that went with it > > This nearly completes the removal of the old fat file system support , there > are a few little bits left , but they are not worth doing at the moment as we > may want to change those bit anyway later. > > Jason > > On Friday 13 August 2010 14:52:03 Jason wrote: >> Hi >> >> I've changed the files >> divebyfobm1.* to divexact_byfobm1.* >> dive_1.* to divexact_1.* >> divebyff.* to divexact_byff.* >> diveby3.* to divexact_by3c.* >> >> and I renamed the function divexact_fobm1 to divexact_byfobm1 >> >> I not touched any files in the build.vc* directorys , but I did do the x86w >> and x86_64w directorys >> >> I've not changed the test file names to match ie we still have >> t-dive_byff.c rather than t-divexact_byff.c >> >> More to come >> >> Jason >> >> On Friday 13 August 2010 13:34:42 Jason wrote: >> > Hi >> > >> > I going to start on these autotools simplifications now , and hopefully >> > the code is clean enough to finish it . >> > >> > I appear to have my Windows box back alive and well , and after having >> > some trouble with installation of Windows 64 (and 32) and MSVC , I >> > should be able to give the Mingw64 (and 32) a go. >> > >> > Jason >> > >> > On Tuesday 27 July 2010 11:31:55 Jason wrote: >> > > On Tuesday 27 July 2010 11:16:25 Bill Hart wrote: >> > > > On 27 July 2010 11:09, Jason <ja...@njkfrudils.plus.com> wrote: >> > > > > Hi >> > > > > >> > > > > Just thinking about the next bit of autotools simplifications , >> > > > > then these bits are all interconnected in some way. >> > > > > >> > > > > Support for fat file systems(8+3 names) , ie we have a file >> > > > > mpn/dive_1.c which gives us the function divexact_1 . We already >> > > > > dont support fat file systems as we already have files with names >> > > > > longer than 8+3 chars , so this is no great loss. So I propose to >> > > > > change the file names to match the function names. >> > > > >> > > > This definitely sounds like a long overdue improvement. >> > > > >> > > > > Some files ie x86/aors_n.asm or mpn/generic/popham.c provide for >> > > > > two functions , and the "decision" is made at compile time , I >> > > > > propose we move the "decision" to "autotools" time. >> > > > >> > > > Do you mean have two symbolic links to the same file with different >> > > > flags for compilation? >> > > >> > > Basically the same setup we have at the moment , but when we run >> > > autotools , we run "our setup script" instead , which runs autotools >> > > AND "splits" aors_n.asm into add_n.asm AND sub_n.asm , that way the >> > > build system doesn't need the compilation FLAGS , ie the build system >> > > is now one file=one function. The complication can still exist , but >> > > are confined to our development machines , so we could write it in >> > > python(or whatever , C?) >> > > >> > > > > There are lists of functions that have to be filled in various >> > > > > Makefile.am 's , with the above changes we should be able to >> > > > > automate it , and I think the Windows build could benefit from the >> > > > > code that can list the files/functions. It would nice if this >> > > > > could handle the function prototypes in the header files as well. >> > > > >> > > > This would be nice. >> > > >> > > There are of course files which can have multiple entry points , ie >> > > mpn_add_n and mpn_add_nc , we would need to handle them , and I think >> > > there are file which have a few functions in them (for tuning only?) . >> > > Have to think about that.... >> > > >> > > > > I need to think about this some more , dont want to start it and >> > > > > get half way through , and realize I should of done it a different >> > > > > way :) >> > > > > >> > > > > 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. > > -- > 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. > > -- 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.
