From: Wheeler, F. (Research) <wh...@cr...> - 2002-12-12 16:23:23
|
> From: Ian Scott [mailto:ian...@st...] > > > 2. Creating the DLLs using the TargetJr method. TargetJr makes .def > > files for each DLL by running dumpbin on the .obj files > through a perl > > script. > > Not that you shouldn't go ahead and submit, but I think option 2 is a > "better" solution. In particular I am a little worried about > polluting the > source with tousands of VXL_EXPORTs, etc. merely because it is MS's > recommeded way of dealing with the appalling design decisions > they made with > dlls. Keeping all the VXL_EXPORTS correct and consistent will > be difficult > for someone not building dlls under windows. One issue with option 2 is that anyone building DLLs will have to have perl installed, assuming we grab the obj->dumpbin->.def translator from TargetJr. Personally, I don't think this is too much to ask, but others may disagree. It might take some CMake changes to use method 2. Target uses makefiles, so it is easy for them to integrate the obj->dumpbin->.def translator into the build. I think you are right about keeping all the VXL_EXPORTS correct. If we use the declspec method, then those who build DLLs will end up adding or correcting the markup to code written by others. -Fred |
From: William A. H. <bil...@ny...> - 2002-12-12 16:44:02
|
There are some differences with the .def and declspec approaches. The declspec version tends to make smaller libraries. Neither approach fixes the STL dll problem. One other approach is to extend cmake to support the creation of the .def file and dump the use of perl. I have thought about it, and it should not be that hard. I would definitely be against requiring perl, most folks just do not have perl installed on windows. The hard part would be getting .def file to be created after all the .o files are created but before the library is created. It will take a few changes in the generators to support the pre-build rules. Any takers? I can help... -Bill At 11:22 AM 12/12/2002 -0500, Wheeler, Fred (Research) wrote: >> From: Ian Scott [mailto:ian...@st...] >> >> > 2. Creating the DLLs using the TargetJr method. TargetJr makes .def >> > files for each DLL by running dumpbin on the .obj files >> through a perl >> > script. >> >> Not that you shouldn't go ahead and submit, but I think option 2 is a >> "better" solution. In particular I am a little worried about >> polluting the >> source with tousands of VXL_EXPORTs, etc. merely because it is MS's >> recommeded way of dealing with the appalling design decisions >> they made with >> dlls. Keeping all the VXL_EXPORTS correct and consistent will >> be difficult >> for someone not building dlls under windows. > >One issue with option 2 is that anyone building DLLs will have to have perl installed, assuming we >grab the obj->dumpbin->.def translator from TargetJr. Personally, I don't think this is too much to >ask, but others may disagree. > >It might take some CMake changes to use method 2. Target uses makefiles, so it is easy for them to >integrate the obj->dumpbin->.def translator into the build. > >I think you are right about keeping all the VXL_EXPORTS correct. If we use the declspec method, then >those who build DLLs will end up adding or correcting the markup to code written by others. > >-Fred > > >------------------------------------------------------- >This sf.net email is sponsored by: >With Great Power, Comes Great Responsibility >Learn to use your power at OSDN's High Performance Computing Channel >http://hpc.devchannel.org/ >_______________________________________________ >Vxl-maintainers mailing list >Vxl...@li... >https://lists.sourceforge.net/lists/listinfo/vxl-maintainers |