From: Wheeler, F. W (Research) <wh...@cr...> - 2004-01-07 16:17:06
|
A few months ago I took a stab at compiling VXL with mingw. I found that VXL would need a lot of defined(__MINGW32__) additions near existing defined(__CYGWIN__) statements. vpl has trouble because the mingw environment is not POSIX enough, but that should be easy to fix up. The commands I used to set up the build are below. Fred Wheeler mkdir -p $TOP/vxl_bld_mingw rm -f $TOP/vxl_bld_mingw/CMakeCache.txt cd $TOP/vxl_bld_mingw cmake \ -G"Unix Makefiles" \ -DCMAKE_INSTALL_PREFIX:PATH=$TOP/vxl_usr_mingw \ -DCMAKE_C_COMPILER:FILEPATH=/usr/bin/gcc \ -DCMAKE_CXX_COMPILER:FILEPATH=/usr/bin/g++ \ -DCMAKE_C_LINK_SHARED:FILEPATH=/usr/bin/gcc \ -DCMAKE_CXX_LINK_SHARED:FILEPATH=/usr/bin/g++ \ -DCMAKE_C_FLAGS:STRING="-Wall -g -O0 -mno-cygwin" \ -DCMAKE_CXX_FLAGS:STRING="-Wall -g -O0 -mno-cygwin" \ -DX11_X11_INCLUDE_PATH:PATH=IGNORE \ -DVXL_FORCE_V3P_ZLIB:BOOL=YES \ -DVXL_FORCE_V3P_PNG:BOOL=YES \ -DVXL_FORCE_V3P_JPEG:BOOL=YES \ -DVXL_FORCE_V3P_MPEG2:BOOL=YES \ -DVXL_FORCE_V3P_TIFF:BOOL=YES \ -DBUILD_VGUI:BOOL=YES \ -DCMAKE_VERBOSE_MAKEFILE:BOOL=OFF \ $TOP/vxl_src cd $TOP/vxl_bld_mingw time make -i > -----Original Message----- > From: Andrew Fitzgibbon [mailto:aw...@ro...] > Sent: Wednesday, January 07, 2004 10:35 AM > To: vxl...@li... > Cc: 'Simon Perkins'; 'Mark Galassi' > Subject: [Vxl-users] RE: VXL binaries for Windows? > > > > > Hi all, > > Reply to Mark please. > > > -----Original Message----- > > From: Mark Galassi [mailto:ro...@ga...] > > Sent: 07 January 2004 06:43 > > To: Andrew Fitzgibbon > > Cc: Mark Galassi; Simon Perkins > > Subject: VXL binaries for Windows? > > > > > > > > Dear Andrew, > > > > I work with Simon Perkins and he suggested that I get in touch with > > you with a VXL question. > > > > Simon and I are using a small part of VXL in a large software > > project. The project needs to build on both POSIX systems > and Windows > > running MinGW (the Minimalist GNU for Windows, which allows > > applications to have native Windows behavior/feel using gcc -- the > > easier approach of using Cygwin does not give the native > feel and does > > not allow the use of the Gtk widgets, which we use for our GUI. > > > > So for our project we need to prepare binary packages for GNU/Linux > > and for Windows. I have prepared an RPM spec file for vxl > (as well as > > a pkg-config description for it), and also source and binary RPMs. > > > > Now I am turning my attention to the Windows/MinGW port. I see that > > VXL comes with instructions and customization for building on Cygwin > > and with Visual Studio, but there is no reference to using > MinGW, and > > the web site does not offer prebuilt Windows binaries. > > > > I wonder if you could: > > > > 1. Let me know to whom I can send my .spec file, RPMs and other > > things. > > > > 2. Do you know of anyone who has used MinGW to build vxl? Naively > > using MinGW it does not work too well because the build system > > concludes that the compiler is Visual C++ instead of GCC, and > > various things go wrong. > > > > 3. Do you know of pre-built Windows binaries of any sort? > > > > Thank you in advance, > > > > Mark Galassi > > > > the RPM and vxl.spec and vxl.pc at > http://www.nis.lanl.gov/~rosalia/vxl/ > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Perforce Software. > Perforce is the Fast Software Configuration Management System offering > advanced branching capabilities and atomic changes on 50+ platforms. > Free Eval! http://www.perforce.com/perforce/loadprog.html > _______________________________________________ > Vxl-users mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-users > |
From: Wheeler, F. W (Research) <wh...@cr...> - 2004-01-08 14:56:31
|
> Mark Galassi wrote: > > Sadly this does not seem to be the case: I have had no success using > cmake with gcc/MinGW on Windows. This is really the stumbling point > on the entire VXL: that cmake does not set things up properly for > MinGW. CMake-MinGW support is much better than I realized just yesterday. I'm compiling in cygwin using the cygwin installed version of gcc and the -mno-cygwin option to use MinGW. I guess you could be using MinGW outside of Cygwin, which could be different. According to Bill Hoffman's posts to the CMake mailing list the key is to use the Windows version of CMake and to generate Unix Makefiles. http://www.cmake.org/pipermail/cmake/2003-August/004240.html The configuration commands I'm using now are below. vcl/testlib/vpl/vsl/vbl and some other core libs compile fine. vil/vnl will need tweaks for MinGW. I'm looking into this myself, but can't make any guarantees. At a glance some problems have to do with IO and isnan(). Fred Wheeler # may need to add defined(__MINGW32__) here and these mkdir -p $TOP/vxl_bld_min rm -f $TOP/vxl_bld_min/CMakeCache.txt cd $TOP/vxl_bld_min # use the windows version of cmake, but make Unix Makefiles "/cygdrive/c/Program Files/CMake/bin/cmake" \ -G"Unix Makefiles" \ -DCMAKE_INSTALL_PREFIX:PATH="`cygpath -w $TOP/vxl_usr_min`" \ -DCMAKE_C_COMPILER:FILEPATH="`cygpath -w /usr/bin/gcc`" \ -DCMAKE_CXX_COMPILER:FILEPATH="`cygpath -w /usr/bin/g++`" \ -DCMAKE_C_LINK_SHARED:FILEPATH="`cygpath -w /usr/bin/gcc`" \ -DCMAKE_CXX_LINK_SHARED:FILEPATH="`cygpath -w /usr/bin/g++`" \ -DCMAKE_C_FLAGS:STRING="-Wall -g -O0 -mno-cygwin" \ -DCMAKE_CXX_FLAGS:STRING="-Wall -g -O0 -mno-cygwin" \ -DX11_X11_INCLUDE_PATH:PATH=IGNORE \ -DVXL_FORCE_V3P_ZLIB:BOOL=YES \ -DVXL_FORCE_V3P_PNG:BOOL=YES \ -DVXL_FORCE_V3P_JPEG:BOOL=YES \ -DVXL_FORCE_V3P_MPEG2:BOOL=YES \ -DVXL_FORCE_V3P_TIFF:BOOL=YES \ -DBUILD_VGUI:BOOL=NO \ -DCMAKE_VERBOSE_MAKEFILE:BOOL=OFF \ "`cygpath -w $TOP/vxl_src`" cd $TOP/vxl_bld_min time make -i time make -i |
From: Simon P. <si...@pe...> - 2004-01-07 17:04:40
|
On Wed, 2004-01-07 at 09:14, Wheeler, Frederick W (Research) wrote: > A few months ago I took a stab at compiling VXL with mingw. I found that > VXL would need a lot of defined(__MINGW32__) additions near existing > defined(__CYGWIN__) statements. vpl has trouble because the mingw > environment is not POSIX enough, but that should be easy to fix up. If it makes any difference, we're really only interested in the VNL parts of VXL at the moment. Has anyone packaged up VNL for windows? Cheers, Sy |
From: Kent W. <nor...@ui...> - 2004-01-08 00:04:39
|
If you look at ITK http://www.itk.org -- ITK hijacks just the vnl parts of VXL. 2 things: 1) I'd start from the current CVS version of ITK and 2) while there are no patches or changes to vnl to fit it into ITK, you will have to extract it from the ITK build environment. The vnl stuff is in Insight/Utilities/vxl. It's set up to configure with CMake, so it should build easily on windows. On Wed, 2004-01-07 at 11:04, Simon Perkins wrote: > On Wed, 2004-01-07 at 09:14, Wheeler, Frederick W (Research) wrote: > > A few months ago I took a stab at compiling VXL with mingw. I found that > > VXL would need a lot of defined(__MINGW32__) additions near existing > > defined(__CYGWIN__) statements. vpl has trouble because the mingw > > environment is not POSIX enough, but that should be easy to fix up. > > If it makes any difference, we're really only interested in the VNL > parts of VXL at the moment. Has anyone packaged up VNL for windows? > > Cheers, > > Sy > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Perforce Software. > Perforce is the Fast Software Configuration Management System offering > advanced branching capabilities and atomic changes on 50+ platforms. > Free Eval! http://www.perforce.com/perforce/loadprog.html > _______________________________________________ > Vxl-users mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-users |
From: Mark G. <ro...@ga...> - 2004-01-08 00:43:20
|
Kent> If you look at ITK http://www.itk.org -- ITK hijacks just Kent> the vnl parts of VXL. Thanks for the tip!! Kent> 2 things: 1) I'd start from the current CVS version of ITK Kent> and 2) while there are no patches or changes to vnl to fit Kent> it into ITK, you will have to extract it from the ITK build Kent> environment. I'll try it. Kent> The vnl stuff is in Insight/Utilities/vxl. It's set up to Kent> configure with CMake, so it should build easily on windows. Sadly this does not seem to be the case: I have had no success using cmake with gcc/MinGW on Windows. This is really the stumbling point on the entire VXL: that cmake does not set things up properly for MinGW. Still, having vnl isolated is awesome! I wonder if the ITK people plan to really isolate it and shipt it as a separate library. |
From: Andrew F. <aw...@ro...> - 2004-01-08 09:19:19
|
VXL has failed us if people want to extract vnl and ship it separately. The whole point of vxl was that someone could install it all, and just use a part of it without having to use all of it. Why is it easier to install ITK than VXL? > -----Original Message----- > From: vxl...@li... > [mailto:vxl...@li...] On Behalf Of > Mark Galassi > Sent: 08 January 2004 00:43 > To: nor...@ui... > Cc: Simon Perkins; Wheeler, Frederick W (Research); vxl-list; > 'Simon Perkins' > Subject: Re: [Vxl-users] RE: VXL binaries for Windows? > > > > Kent> If you look at ITK http://www.itk.org -- ITK hijacks just > Kent> the vnl parts of VXL. > > Thanks for the tip!! > > Kent> 2 things: 1) I'd start from the current CVS version of ITK > Kent> and 2) while there are no patches or changes to vnl to fit > Kent> it into ITK, you will have to extract it from the ITK build > Kent> environment. > > I'll try it. > > Kent> The vnl stuff is in Insight/Utilities/vxl. It's set up to > Kent> configure with CMake, so it should build easily on windows. > > Sadly this does not seem to be the case: I have had no success using > cmake with gcc/MinGW on Windows. This is really the stumbling point > on the entire VXL: that cmake does not set things up properly for > MinGW. > > Still, having vnl isolated is awesome! I wonder if the ITK people > plan to really isolate it and shipt it as a separate library. > > > ------------------------------------------------------- > This SF.net email is sponsored by: Perforce Software. > Perforce is the Fast Software Configuration Management System offering > advanced branching capabilities and atomic changes on 50+ platforms. > Free Eval! http://www.perforce.com/perforce/loadprog.html > _______________________________________________ > Vxl-users mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-users > |
From: Simon P. <si...@pe...> - 2004-01-08 16:06:58
|
For us, the main issue is just size. VXL is a big piece of software. The linux RPM we just made that includes all of VXL is 85MB! That's a non-trivial amount of (mostly unused) code to insist that our customers download. A second issue is compilation time. Compiling just VNL takes about 6 minutes for us. Compiling all of VXL takes about 40 minutes. Cheers, Sy > -----Original Message----- > From: Andrew Fitzgibbon [mailto:aw...@ro...] > Sent: Thursday, January 08, 2004 2:19 AM > To: 'Mark Galassi'; nor...@ui... > Cc: 'Simon Perkins'; 'Wheeler, Frederick W (Research)'; 'vxl-list'; 'Simon > Perkins' > Subject: RE: [Vxl-users] RE: VXL binaries for Windows? > > > VXL has failed us if people want to extract vnl and ship it separately. > The whole point of vxl was that someone could install it all, and just > use a part of it without having to use all of it. > > Why is it easier to install ITK than VXL? > > > |
From: Ian S. <ian...@st...> - 2004-01-09 16:13:56
|
VXL-maintainers are unlikely to want to support a separated VNL, but it appears that there is a demand for just VNL binaries. We could deal with both requirements by putting a "BUILD_VNL_ONLY" option into the CMakeLists. I guess it depends what people need, but it could build just vcl, netlib, vnl and vnl_algo. Comments? Ian. > -----Original Message----- > From: vxl...@li... > [mailto:vxl...@li...]On Behalf Of > Simon Perkins > Sent: Thursday, January 08, 2004 4:07 PM > To: 'Andrew Fitzgibbon'; 'Mark Galassi'; nor...@ui... > Cc: 'Wheeler, Frederick W (Research)'; 'vxl-list'; 'Simon Perkins'; > Simon Perkins > Subject: RE: [Vxl-users] RE: VXL binaries for Windows? > > > For us, the main issue is just size. VXL is a big piece of > software. The > linux RPM we just made that includes all of VXL is 85MB! That's a > non-trivial amount of (mostly unused) code to insist that our > customers > download. > > A second issue is compilation time. Compiling just VNL takes about 6 > minutes for us. Compiling all of VXL takes about 40 minutes. > > Cheers, > > Sy > > > > -----Original Message----- > > From: Andrew Fitzgibbon [mailto:aw...@ro...] > > Sent: Thursday, January 08, 2004 2:19 AM > > To: 'Mark Galassi'; nor...@ui... > > Cc: 'Simon Perkins'; 'Wheeler, Frederick W (Research)'; 'vxl-list'; > 'Simon > > Perkins' > > Subject: RE: [Vxl-users] RE: VXL binaries for Windows? > > > > > > VXL has failed us if people want to extract vnl and ship it > separately. > > The whole point of vxl was that someone could install it > all, and just > > use a part of it without having to use all of it. > > > > Why is it easier to install ITK than VXL? > > > > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Perforce Software. > Perforce is the Fast Software Configuration Management System offering > advanced branching capabilities and atomic changes on 50+ platforms. > Free Eval! http://www.perforce.com/perforce/loadprog.html > _______________________________________________ > Vxl-users mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-users > |
From: Andrew F. <aw...@ro...> - 2004-01-09 17:06:48
|
I think it might be better to have switches for each of the core libraries. We always intended that people should be able to build only part of VXL, so it might make sense to configure the various parts separately. I.e. have BUILD_NUMERICS # Build VNL and all dependencies BUILD_IMAGING # vil BUILD_UTILITIES # vpl, vul, vbl BUILD_SERIALIZATION # vsl BUILD_VIDEO # vidl BUILD_GUI # vgui BUILD_GEOMETRY # vgl, vcsl, vtol and so on. It also means that new users see immediately that they need not add all libraries, and then Mark and Simon's build would be far less than 80MB. The curious can later easily add libraries. In my opinion, this is a particular selling point for VXL: because we've taken care to keep modules separately buildable, we should make it easy to configure it. I also feel it's better to use the descriptive names (Numerics, Serialization, etc) rather than the easy-to-type names vnl, vsl and so on. And I commend my .02 euros to the house. A. |
From: Peter V. <Pet...@es...> - 2004-01-08 08:55:16
|
> Still, having vnl isolated is awesome! Why? vnl was designed to be stand-alone. What are the problems? -- Peter. |
From: Mark G. <ro...@ga...> - 2004-01-08 11:10:42
|
>> Still, having vnl isolated is awesome! Peter> Why? vnl was designed to be stand-alone. What are the Peter> problems? I did not know that: can you tell me where I can pick up a vnl-only package? |
From: Peter V. <Pet...@es...> - 2004-01-08 11:16:17
|
> Peter> Why? vnl was designed to be stand-alone. What are the > Peter> problems? > > I did not know that: can you tell me where I can pick up a vnl-only > package? vnl is packaged with the rest of vxl, but you can just compile vnl and remove the rest. Except for v3p/netlib and vcl. vnl/algo needs netlib. -- Peter. |