CGAL users discussion list

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

Le jeudi 31 janvier 2013 16:14:31 Jeffrey Bush a écrit :
> Thanks for your input. I had a long frustrating day yesterday and I may
> have taken some of it out on the list...
> 
> *Installation path recommendation*: use %ProgramW6432% instead of the
> %ProgramFiles% directive. Basically always install to C:\Program Files\ (or
> whatever it has been renamed to) regardless if the OS is 32-bit or 64-bit.
> Your installer is 32-bit, but since you don't really have any compiled code
> (except the aux stuff which is already both) you should probably install to
> the native program files. This would have the side-effect of fixing the Qt
> cmake script issue.

For the next release, our setup.exe will install in:
  C:\Program Files\CGAL-4.2

However, I hope that modification of our setup program will not break on pure 
32 bits Windows version. GeometryFactory no longer have pure 32 bits version 
of Windows to test with.

> *Parenthesis issue*: sorry for blaming you, didn't realize this was a Qt
> issue! Sorry!

It is a CMake issue. CMake scripts for Qt4 are maintained and shipped in the 
CMake distribution. I wonder if the Qt5 CMake scripts, maintained in the Qt5 
distribution itself, will have any similar issues. I have not yet tested.

> *Alternate build path*: thanks for that tip as well. I didn't really
> understand the differentiation. I actually thought that was only where the
> finally binaries would be output to.

That is where any file generated by CMake will be put. The really "final 
destination" of binaries is the result of the "installation" (with Microsoft 
Visual Studio, that is when one "build" the "INSTALL" project in the CGAL 
solution), and the installation process has its own destination directory, 
that can be different from the other two.

> *Boost auto-linking*: not working. When configuring your cmake then going
> into VS and compiling I get numerous unresolved link errors, all related to
> boost. Specifying the appropriate boost libs in the linker input options in
> VS resolves the issue. Maybe something else is going on here... I am going
> to try to re-do all my Windows building following the Windows guide and
> maybe it will go away. I do recommend you link to the guide from the
> official manual though.

That is really strange. The auto-linking is used to construct the name of the 
library from the version of the compiler and some compiler flags. For 
example, 
The Boost.Thread library from Boost-1.50, when:
  - Microsoft Visual Studio 2008 (vc9) is used,
  - in Debug mode,
  - for a Boost library using the dynamic C and C++ runtimes,
  - and for a static version of Boost libraries,
then the name is:
  libboost_thread-vc90-mt-gd-1_50.lib

If that is:
  - Microsoft Visual Studio 2010 (vc10) is used,
  - in Release mode,
  - for a Boost library using the dynamic C and C++ runtimes,
  - and for a DLL version of Boost libraries,
then the name is:
  boost_thread-vc100-mt-1_50.lib


The FindBoost module, in CMake, is smart enough to find out what are the 
right 
names of the Boost libraries to link with. However, in CGAL, even if we use 
the FindBoost.cmake module, we have decided not to disable Boost auto-linking 
features.

But Boost auto-linking is architecture-agnostic, so far. So users have to be 
careful that the linking path contains the right directory to Boost 
libraries, 
for the right architecture. Maybe you have 64 bits Boost libraries installed, 
and try to link them with a 32 bits binary, or the reverse.


I am not sure that the choice to use Boost auto-linking within CGAL is the 
right one. Maybe we should just use the names given by the CMake module 
FindBoost. I currently do not have a lot of time to work on that subject.


Anyway, your troubles are probably due to a bad mix you may have configured 
without noticing. Please double-check.
 
> *In terms of the AABB_demo*: I don't have a modified version of Windows, I
> am using MS Security Essentials anti-virus which is one of the most
> friendly (in terms of interacting with your system) ones out there. No
> broken hard drive (actually SSD and HDD). I tried to compile many times, in
> debug mode and in release mode. The only other time I have seen this error
> (in particular that error code) is when loading 32-bit DLLs from a 64-bit
> program or vice-a-versa.

Probably due to a bad mix of 32/64 binaries, indeed. Have a look at your 
linker warnings: there should be an hint that something got wrong.

> After I rebuild CGAL I will see if maybe something
> like that is happening. Odd thing is that running that same demo in my
> CentOS virtual machine causes the entire virtual machine to crash... but
> that could be because of lack of most 3D graphics support. In both cases
> the AABB_examples were able to run just fine (on Windows and Linux). Now
> trying on a real CentOS machine (not virtual).

GeometryFactory do have a CentOS server (and Fedora desktops), so daily test 
the Linux support. Our CentOS server is remote and headless, so I have never 
tried to run any graphical application on it.
 
> *Creating project using CGAL:* I tried that and there were still some
> issues, but maybe rebuilding CGAL right will address them. One thing that I
> did notice and remember right away is that the MS Intellisense compiler has
> some issues with the CGAL headers. It shows compile errors that make no
> sense (if you consider the project properties).

My college working on Window with Visual Studio sees the same meaningless 
errors reported by Intellisense. I do not have any clue how to understand and 
fix those errors.

> Maybe you can detect the
> Intellisense compiler with some preprocessor macros to hide some of the
> CGAL header code from it? There are other reports of the Intellisense
> compiler not giving accurate results (the one that first comes to mind is
> that it treats all code as C++ even if it is compile as C/has a .c
> extension).

I do not find any way to run any automatic testing using the Intellisense 
compiler. That will be very hard for the CGAL project to debug the errors 
reported by that "compiler", and find workarounds. Is there any programmatic 
way to call that Intellisense compiler externally to the Visual Studio IDE?

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