CGAL users discussion list

["Laurent Rineau (CGAL/GeometryFactory)" <>]

Le vendredi 01 février 2013 13:57:27 Jeffrey Bush a écrit :
> Setup install path: doing a bit more research %ProgramW6432% does not exist
> on 32-bit systems. So the best option is to use %ProgramW6432% if defined,
> else use %ProgramFiles% (hopefully your installer system allows for that
> logic). For testing installers, you could just use VirtualPC with the free
> images supplied at
> http://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=11575
> which
> are all 32-bit images and last for 90 days or unlimited by using undo disks.

On Friday morning, I have managed to encode a similar thing in the sources of 
our NSIS installer. And I have tested on my Linux machine, using the Windows 
emulator, both in 32 and 64 bits (using wine and wine64).

> Boost auto-linking: this time around everything worked. I followed the
> Windows-specific guide. The main differences I saw were using Tom's Boost
> libraries instead of Boostpro and setting some additional environmental
> variables that I normally set in . I think Boostpro's version number was
> off.

Good. That is what was expected.

> AABB_demo is now working on Windows. Soon to test on CentOS machine (had to
> wait for admins to install some of the prerequisites). I think the bad
> image format thing didn't show up during the compile since the LIB was
> right, but the DLL used was wrong. The compiler/linker doesn't look at the
> DLL.

You can debug the DLL hell using the tool depends.exe:
  http://www.dependencywalker.com/

> Intellisense: I don't really have any experience with this but doing a
> quick Google search I come up with using #ifndef __INTELLISENSE__ ....
> #endif to hide code from Intellisense (
> http://stackoverflow.com/questions/6496524/hide-a-c-code-block-from-intellis
> ense) and a general article on the Intellisense compiler in VS2010 on the
> MSDN blog
> (http://blogs.msdn.com/b/vcblog/archive/2011/03/29/10146895.aspx). On
> calling it programmatically, I have no idea.

Without being able to test it automatically, that will be difficult to find 
out which workarounds are needed to make it accept CGAL and Boost code.
 
> *** New Problems ***

Unfortunately, all the problems you have found out are known by the CGAL 
developers team (thanks to our daily test suite), but nobody is motivated 
enough to work on a solution. That is why I must concede that our MSVS 
support 
is only 97%.

> *Error: algebraic_segments and algebraic_curves: specialization conversions
> not possible*
> error C2440: 'specialization' : cannot convert from 'CORE::BigRat
> std::_Pair_base<_Ty1,_Ty2>::* ' to 'CORE::BigRat std::pair<_Ty1,_Ty2>::* '
> C:\CGAL\CGAL-4.1\include\CGAL\Algebraic_kernel_d\LRU_hashed_map.h line 89
> error C2440: 'specialization' : cannot convert from 'CORE::BigRat
> std::_Pair_base<_Ty1,_Ty2>::* ' to 'CORE::BigRat std::pair<_Ty1,_Ty2>::* '
> C:\CGAL\CGAL-4.1\include\CGAL\Algebraic_kernel_d\LRU_hashed_map.h line 89

Nobody really understood what happens here. That looks like a Microsoft 
compiler bug, but we are unsure. No workaround is known.

> *Error: **Kinetic_Delaunay_triangulation_3: argument type problems*
> error C2665:
> 'CGAL::Kinetic::internal::Delaunay_3_edge_flip_event<KD,RS>::Delaunay_3_edge
> _flip_event'
> : none of the 2 overloads could convert all the argument types
> 
> C:\CGAL\CGAL-4.1\include\CGAL\Kinetic\internal\Delaunay_triangulation_base_3
> .hline 877

Same here. We do not know if that is a bug of the code or a bug of the 
compiler. The other compilers accept the code.
> 
> *Error: **Many demos/examples unable to compile in debug mode due to
> "number of sections exceeded object file format limit" (error number
> C1128<http://msdn.microsoft.com/en-us/library/8578y171(v=vs.100).aspx>
> -
> they have suggestions for fixing). *Note that they say it is 3x easier to
> hit this limit on 64-bit then 32-bit and without debug mode is a lot
> better. Also splitting up source files into multiple files helps. The
> most straight-forward solution is to add the command line argument /bigobj
> for compiliation of these projects.

That is known issue. The only known workaround is /bigobj

> *Warning: Kinetic_regular_triangulation_3 - type name first seen using
> 'struct' now seen using 'class' - *Seems like something that should be
> addressed, one should be renamed so that they aren't conflicting
> warning C4099:
> 'CGAL::Kinetic::Regular_triangulation_3<TraitsT,VisitorT,TriangulationT>::D
> elaunay_visitor'
> : type name first seen using 'struct' now seen using 'class'
> 
> C:\CGAL\CGAL-4.1\include\CGAL\Kinetic\Regular_triangulation_3.h 360
> warning C4099:
> 'CGAL::Kinetic::Regular_triangulation_3<TraitsT>::Delaunay_visitor'
> : type name first seen using 'struct' now seen using 'class'
> 
> C:\CGAL\CGAL-4.1\include\CGAL\Kinetic\Regular_triangulation_3.h 360

I agree those warnings should be fixed.

> *Warning: polyhedron_ex_parameterization and Taucs_parameterization
> - defaultlib 'MSVCRT' conflicts with use of other libs; use
> /NODEFAULTLIB:library*
> Some conflict in the C library being used in these projects

Taucs is a third-library that we are replacing by the use of Eigen3. There 
was 
too many issues with Taucs.

> *Warning: 99 warnings about conversion of __int64 to int and 329 warnings
> about conversion of size_t to (unsigned) int or long*
> This is a lot of errors/warnings about int usage problems, specifically
> about running on a 64-bit system probably. For a complete list of
> projects/lines with this error, see the attached xslx spreadsheet.
> 
> *Warning: 4 warnings about conversion of double to float*
> Seems a bit more important to address since it effects 32 and 64 bit and
> Linux and Windows. Details in attached spreadsheet.
> 
> *Warning: 23 warnings about forcing int / void* / CGAL::Sign to true /
> false as a performance warning*
> Add a cast to remove warning, but otherwise just a quirk of MSVC.

Those warnings should be fixed. That is a long work, and nobody in the CGAL 
team seems interested in fixing all of them. Sadly.

> *Warning: 373 warnings about decorated names exceeding length and being
> truncated*
> Probably nothing that can be done about this, but is a quirk of MSVC.

For those one, you are right that we cannot do much.

-- 
Laurent Rineau, PhD
R&D Engineer at GeometryFactory           http://www.geometryfactory.com/
Release Manager of the CGAL Project       http://www.cgal.org/