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.
