[osg-submissions] API configurations in a seperate Config include file

[Mathias Fröhlich]

Robert,

On Monday 23 June 2008 11:50, Robert Osfield wrote:
> I haven't done the background work on CMake/Config files so I have to
> defer to your experience with this.  In terms of what makes sense as a
> layman, to me having headers lists as headers along with the rest of
> the headers seems logical.  Having extra headers "automagically" be
> added to the header list is less intuitive.
Well, these are not traditional headers in the source file sense. Because of 
this files not being available at configure time. Files  not available at 
configuration time are usually treated in a different way. You can observe 
this with most build/configuration systems.
So, special needs  - special treatment ...

> As a test I've put a # in front of the INSTALL_FILES directive for the
> two Config files, this works fine, removing the double install.  I've
> now checked in this tweak.
>
> The open question for me, is does the config setup code automatically
> put the headers into the OpenThreads_PUBLIC_HEADERS and
> LIB_PUBLIC_HEADERS?  If it does then my own additions would break
> this, but I kinda doubt this is happening as otherwise the
> INSTALL_FILES directive you added wouldn't have been required.

Hmm, Ok, I begin to see what you are aiming to.
Sorry, I should have read better what you write.
Additionally I have looked into the win32/win64 stuff we had offlist today 
morning, changes attached.

IMO, this config file should *not* appear in any IDE project source file list, 
even if it is included by many files it is not a source file that should be 
changed. The source of what is in there is the cmake configured stuff in 
cmake's cache.

- Having that file in the project file list would make me assume that I can 
edit this file. Ok, I *can* edit, but I cannot rely on such changes to be 
persistent, since cmake might overwrite that file at the next time cmake 
runs...
So, I believe that it is better to not present that file by default to an IDE 
user ...
If you want to have this config file changed in a persistent way, you need to 
run cmake or ccmake - don't point a user to the wrong config file.

- Setting the include path is sufficient to make the compiler find this file - 
you do not need a source file entry in the IDE project file for that.
... At least for msvc. Is this true for oither ide's too?

Open questions:
I do not know what happens with build dependencies, but I hope and still 
assume that these are found by an other mechanism than specifying them by 
hand.
I also do not know what happens with apples build system here.

BTW: I believe we sould add some
// Automatically created by cmake - do not edit ... [and so on]
to that Config.in files to warn the user that this file should not be changed 
directly.

I still believe that it's better to do what I have provided. But leave it the 
way it is if you want to - it appears to work.

Anyway, different topic: fixed win32/win64 configure check and win32/win64 
atomic related compile failures with msvs2005. Attached changes to make win32 
really use the atomic stuff. There are pointer typecast problems and some 
historic alignment restrictions that I just took from a previous similar 
implementation of mine without looking deep enough. Change is on top of rev 
8487.

Other compile fixes for win32 pending ...

GReetings
 Mathias

-- 
Dr. Mathias Fröhlich, science + computing ag, Software Solutions
Hagellocher Weg 71-75, D-72070 Tuebingen, Germany
Phone: +49 7071 9457-268, Fax: +49 7071 9457-511
-- 
Vorstand/Board of Management:
Dr. Bernd Finkbeiner, Dr. Florian Geyer,
Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech
Vorsitzender des Aufsichtsrats/
Chairman of the Supervisory Board:
Prof. Dr. Hanns Ruder
Sitz/Registered Office: Tuebingen
Registergericht/Registration Court: Stuttgart
Registernummer/Commercial Register No.: HRB 382196 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: CheckAtomicOps.cmake
Type: text/x-csrc
Size: 2776 bytes
Desc: not available
URL: <http://lists.openscenegraph.org/pipermail/osg-submissions-openscenegraph.org/attachments/20080623/bbfccd07/attachment-0001.c>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Atomic
Type: text/x-c++hdr
Size: 5254 bytes
Desc: not available
URL: <http://lists.openscenegraph.org/pipermail/osg-submissions-openscenegraph.org/attachments/20080623/bbfccd07/attachment-0001.hpp>