I've updated my github rtt-2.0-mainline branch with the latest cmake patches.
http://github.com/psoetens/orocos-rtt/tree/rtt-2.0-mainline
The main accomplishments are:
* Fairly portable, normally no GNU/GCC specific flags/instructions present[*]
* Should work very well with non-standard installs of dependencies
* Created FindX.cmake for each dependency, or re-used existing one
* Followed all 'good practice' cmake conventions (naming, using lists,
passing flags etc)
* The structure and meaning is now much clearer
* Flags for .pc files are automatically derived from cmake lists, so
no double bookkeeping.
[*],[**] The only thing not fully ported now is the FindTAO and
FindOmniorb scripts.
Since they don't use the recommended cmake library lists (ie
'/usr/lib/libTAO.so;/usr/lib/libACE.so;...)
yet. They also assume to much of a GNU system still.
Clearly, they are next on the table.
Basically, this is 1.8.x with a cleaned up build system, depending on cmake 2.6.
Feel free to look/ask.
Peter
PS: The rtt-2.0-mainline code is standardised on the Boost UTF and
cppunit has been
removed.
CMake progress
On Fri, Jun 5, 2009 at 1:26 PM, Peter Soetens <peter [dot] soetens [..] ...>wrote:
> I've updated my github rtt-2.0-mainline branch with the latest cmake
> patches.
>
> http://github.com/psoetens/orocos-rtt/tree/rtt-2.0-mainline
Great news!
>
>
> The main accomplishments are:
> * Fairly portable, normally no GNU/GCC specific flags/instructions
> present[*]
> * Should work very well with non-standard installs of dependencies
> * Created FindX.cmake for each dependency, or re-used existing one
> * Followed all 'good practice' cmake conventions (naming, using lists,
> passing flags etc)
> * The structure and meaning is now much clearer
> * Flags for .pc files are automatically derived from cmake lists, so
> no double bookkeeping.
>
> [*],[**] The only thing not fully ported now is the FindTAO and
> FindOmniorb scripts.
> Since they don't use the recommended cmake library lists (ie
> '/usr/lib/libTAO.so;/usr/lib/libACE.so;...)
> yet. They also assume to much of a GNU system still.
>
> Clearly, they are next on the table.
>
> Basically, this is 1.8.x with a cleaned up build system, depending on cmake
> 2.6.
> Feel free to look/ask.
Since some of the find scripts are based on the structure I proposed, I have
to say that shortly after sending that proposal to this ML, I found a more
elegant and less verbose/error prone way of doing the same thing :-/. I've
attached a patch for the FindXerces.cmake script so everyone interested can
check it out. As a bonus, the check for unusual install paths is also
different on the patch, it takes into account things mentioned in this
thread [1]. One important point to take from that thread is that if you
change the location of package FOO _after_ cmake has found it (i.e., the
FOO_INCLUDE_DIR and FOO_LIBRARY cache vars have a valid value), changing the
value of FOO_ROOT_DIR will not be enough for finding the newly located FOO.
You also need to unset FOO_INCLUDE_DIR and FOO_LIBRARY. Anyway, this is a
cmake issue and also happends when a package moves between two standard
locations.
Another suggestion: I think that a parallelism between the capitalization of
the find script name and its associated cmake vars would be nice, so if I
type:
find_package(XERCES)
I can expect the script to at least create
XERCES_FOUND
XERCES_INDLUDE_DIRS
XERCES_LIBRARIES
without having to dig into its doc. If, on the other hand, I type
find_package(Xerces)
it's not that clear whether I will get XERCES_FOUND or Xerces_FOUND...
One final note. If you decide not to apply the patch, there is a typo on
line 36 of the script ;) XERCES_depdom_LIBRARY should read
XERCES_DEPDOM_LIBRARY
[1] //www [dot] mail-archive [dot] com/cmake [..] .../msg21767.html" title="http://www [dot] mail-archive [dot] com/cmake [..] .../msg21767.html">http://www [dot] mail-archive [dot] com/cmake [..] .../msg21767.html
Cheers,
Adolfo
>
> Peter
>
> PS: The rtt-2.0-mainline code is standardised on the Boost UTF and
> cppunit has been
> removed.
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>
CMake progress
2009/6/5 Adolfo Rodríguez Tsouroukdissian <adolfo [dot] rodriguez [..] ...>:
>
>
> On Fri, Jun 5, 2009 at 1:26 PM, Peter Soetens <peter [dot] soetens [..] ...>
> wrote:
>> Basically, this is 1.8.x with a cleaned up build system, depending on
>> cmake 2.6.
>> Feel free to look/ask.
>
> Since some of the find scripts are based on the structure I proposed, I have
> to say that shortly after sending that proposal to this ML, I found a more
> elegant and less verbose/error prone way of doing the same thing :-/. I've
> attached a patch for the FindXerces.cmake script so everyone interested can
> check it out. As a bonus, the check for unusual install paths is also
> different on the patch, it takes into account things mentioned in this
> thread [1]. One important point to take from that thread is that if you
> change the location of package FOO _after_ cmake has found it (i.e., the
> FOO_INCLUDE_DIR and FOO_LIBRARY cache vars have a valid value), changing the
> value of FOO_ROOT_DIR will not be enough for finding the newly located FOO.
> You also need to unset FOO_INCLUDE_DIR and FOO_LIBRARY. Anyway, this is a
> cmake issue and also happends when a package moves between two standard
> locations.
Thanks for the update. I came to the same conclusion later-on. The FindTAO macro
is also similar to your approach when a path hint is given by the
user.. However,
I would dare to remove the XERCES_ROOT_DIR because we agreed to use
CMAKE_INCLUDE_DIR
(and variants) to tell where the non-standard locations are. Such a
global search
path scales much better than to specify the root for each package: BOOST_ROOT,
XERCES_ROOT, etc
>
> Another suggestion: I think that a parallelism between the capitalization of
> the find script name and its associated cmake vars would be nice, so if I
> type:
>
> find_package(XERCES)
>
> I can expect the script to at least create
>
> XERCES_FOUND
> XERCES_INDLUDE_DIRS
> XERCES_LIBRARIES
>
> without having to dig into its doc. If, on the other hand, I type
>
> find_package(Xerces)
>
> it's not that clear whether I will get XERCES_FOUND or Xerces_FOUND...
If you look at the CMake Find modules, the majority uses CamelCase for
the file name and uppercase for the variables. Boost is a notable exception.
I'd like to stick to that unwritten rule for now.
>
> One final note. If you decide not to apply the patch, there is a typo on
> line 36 of the script ;) XERCES_depdom_LIBRARY should read
> XERCES_DEPDOM_LIBRARY
I'll apply it anyway, it's an improvement :)
Peter
CMake progress
2009/6/6 Peter Soetens <peter [dot] soetens [..] ...>
> 2009/6/5 Adolfo Rodríguez Tsouroukdissian <
> adolfo [dot] rodriguez [..] ...>:
> >
> >
> > On Fri, Jun 5, 2009 at 1:26 PM, Peter Soetens <peter [dot] soetens [..] ...>
> > wrote:
> >> Basically, this is 1.8.x with a cleaned up build system, depending on
> >> cmake 2.6.
> >> Feel free to look/ask.
> >
> > Since some of the find scripts are based on the structure I proposed, I
> have
> > to say that shortly after sending that proposal to this ML, I found a
> more
> > elegant and less verbose/error prone way of doing the same thing :-/.
> I've
> > attached a patch for the FindXerces.cmake script so everyone interested
> can
> > check it out. As a bonus, the check for unusual install paths is also
> > different on the patch, it takes into account things mentioned in this
> > thread [1]. One important point to take from that thread is that if you
> > change the location of package FOO _after_ cmake has found it (i.e., the
> > FOO_INCLUDE_DIR and FOO_LIBRARY cache vars have a valid value), changing
> the
> > value of FOO_ROOT_DIR will not be enough for finding the newly located
> FOO.
> > You also need to unset FOO_INCLUDE_DIR and FOO_LIBRARY. Anyway, this is a
> > cmake issue and also happends when a package moves between two standard
> > locations.
>
> Thanks for the update. I came to the same conclusion later-on. The FindTAO
> macro
> is also similar to your approach when a path hint is given by the
> user.. However,
> I would dare to remove the XERCES_ROOT_DIR because we agreed to use
> CMAKE_INCLUDE_DIR
> (and variants) to tell where the non-standard locations are. Such a
> global search
> path scales much better than to specify the root for each package:
> BOOST_ROOT,
> XERCES_ROOT, etc
All right, that will simplify even further the find scripts :)
>
>
> >
> > Another suggestion: I think that a parallelism between the capitalization
> of
> > the find script name and its associated cmake vars would be nice, so if
> I
> > type:
> >
> > find_package(XERCES)
> >
> > I can expect the script to at least create
> >
> > XERCES_FOUND
> > XERCES_INDLUDE_DIRS
> > XERCES_LIBRARIES
> >
> > without having to dig into its doc. If, on the other hand, I type
> >
> > find_package(Xerces)
> >
> > it's not that clear whether I will get XERCES_FOUND or Xerces_FOUND...
>
> If you look at the CMake Find modules, the majority uses CamelCase for
> the file name and uppercase for the variables. Boost is a notable
> exception.
> I'd like to stick to that unwritten rule for now.
OK, and since in general I'm not a big fan of ALL_CAPS notation, I'm easy to
convince.
> >
> > One final note. If you decide not to apply the patch, there is a typo on
> > line 36 of the script ;) XERCES_depdom_LIBRARY should read
> > XERCES_DEPDOM_LIBRARY
>
> I'll apply it anyway, it's an improvement :)
>
> Peter
>