Le 09/02/2011 22:31, Peter Soetens a écrit :
> On Wed, Feb 9, 2011 at 7:29 PM, Philippe Hamelin
> <philippe [dot] hamelin [..] ...> wrote:
>> 2011/2/9 Peter Soetens<peter [..] ...>
>>>
>>> I have merged my last patches on master for rtt.
>>>
>>> These are the major changes:
>>>
>>> - All-round fixes for compiling with clang. This didn't break gcc builds,
>>> but
>>> It would be nice if the Win32 guys could check if it didn't break theirs
>>> - 'extern template' declarations for the RTT types in a Types.hpp header.
>>> I
>>> checked with Visual studio documentation, this should be supported.
>>> - Merged all win32 work I could get. The fix for CorbaConversion is still
>>> lacking.
>>>
>>> If anyone could assist me with setting up a hudson job for building
>>> automatically on win32, I'd be happy to include it in my workflow such
>>> that
>>> breakage could be sooner detected.
>>>
>>> Please test this version as the 2.3 release won't be much different than
>>> this.
>>> I pushed updates for rtt, ocl and log4cpp, all on master.
>>>
>>>
>>
>> The win32 build is broken with some linking errors. I will try to fix that
>> this afternoon.
>
> Can you post the missing symbols and when linking which libraries or
> applications ?

A quick feedback.

I'm also investigating this issue. There are severals problem, the
biggest one is due to some changes regarding the DataSources.

The problem arises at least with the shared libraries marshalling and
transport-corba when linking with orocos-rtt library. I think, it's due
to the explicit instantiation of the various datasources in Types*.inc
and their declarations as extern types in Types.h and RTTTypes.h. The
missing symbols are only .*DataSource ones For example:

"public: virtual bool __cdecl RTT::internal::DataSource<class
RTT::ConnPolicy>::evaluate(void)const "
(?evaluate@?$DataSource@VConnPolicy@RTT@@@internal@RTT@@UEBA_NXZ)
"__cdecl RTT::internal::ValueDataSource<class
RTT::ConnPolicy>::ValueDataSource<class RTT::ConnPolicy>(class
RTT::ConnPolicy)"

adding an ifndef WIN32 in Types*.inc, Types.h and RTTTypes.h makes the
project build, but I don't know if I keep the intended behaviour. ie,
the DataSource are not instantiated int the rtt core lib.

Since there are other missing symbols, the tests don't link completelty
with this workaround.

On Feb 9, 2011, at 11:04 , Peter Soetens wrote:

> On Wed, Feb 9, 2011 at 3:09 PM, S Roderick <kiwi [dot] net [..] ...> wrote:
>> On Feb 9, 2011, at 03:50 , Peter Soetens wrote:
>>
>>> I have merged my last patches on master for rtt.
>>>
>>> These are the major changes:
>>>
>>> - All-round fixes for compiling with clang. This didn't break gcc builds, but
>>> It would be nice if the Win32 guys could check if it didn't break theirs
>>
>> Fails to build under clang v1.0.2 on macosx. See Hudson.
>>
>> And it takes an incredibly long time to build ... way longer than gcc ...
>
> Don't be too hasty to draw conclusions :-)
> You need clang 2.9 (master from their git), *and* their
> CMAKE_BUILD_TYPE set to Release *and* compile clang with 'clang built
> with gcc'. Then you build RTT and OCL with that clang. It takes 48
> seconds to build RTT on my slightly overclocked system :-)

Ok ... LOL ... didn't realise that I'd need that much configuration to build a reasonably performing compiler!

I'll try this when I get a chance.
S

2011/2/10 Peter Soetens <peter [..] ...>

> On Wednesday 09 February 2011 14:52:09 Philippe Hamelin wrote:
> > 2011/2/9 Peter Soetens <peter [..] ...>
> >
> > > I have merged my last patches on master for rtt.
> > >
> > > These are the major changes:
> > >
> > > - All-round fixes for compiling with clang. This didn't break gcc
> builds,
> > > but
> > > It would be nice if the Win32 guys could check if it didn't break
> theirs
> > > - 'extern template' declarations for the RTT types in a Types.hpp
> header.
> > > I checked with Visual studio documentation, this should be supported. -
> > > Merged all win32 work I could get. The fix for CorbaConversion is still
> > > lacking.
> > >
> > > If anyone could assist me with setting up a hudson job for building
> > > automatically on win32, I'd be happy to include it in my workflow such
> > > that breakage could be sooner detected.
> >
> > Would you like to run unit tests or just build? Actually, the unit tests
> > doesn't work off-the-shelf. Our actual workaround was to do:
> >
> > make all install test
> >
> > However, I think we should fix that in a near future to avoid the
> "install"
> > before running tests.
>
> We don't require this on Linux. On that platform, the build contains a
> 'cmake -E' instruction that copies the typekit to the build/rtt/types
> directory. We then set the RTT_COMPONENT_PATH to this build/rtt directory,
> but *relatively*, so we must enter the build/tests directory and
> then it will look for typekits in "../rtt". See tests/test-runner.cpp:
>
>

>    // sets environment if not set by user.
>    setenv("RTT_COMPONENT_PATH","../rtt", 0);
> 

>  if (PROJ_BINARY_DIR)
>    add_custom_command(TARGET ${name}-${OROCOS_TARGET}_plugin POST_BUILD
>          COMMAND ${CMAKE_COMMAND} -E make_directory
> ${PROJ_BINARY_DIR}/rtt/types
>          COMMAND ${CMAKE_COMMAND} -E copy ${TYPEKITLIB_DIR}
> ${PROJ_BINARY_DIR}/rtt/types
>          COMMENT "Copying ${TYPEKITLIB_DIR} to ${PROJ_BINARY_DIR}/rtt/types
> ")
>  if (WIN32)
>    get_target_property(DEBUG_TYPEKITLIB_DIR ${name}-${OROCOS_TARGET}_plugin
> DEBUG_LOCATION)
>    add_custom_command(TARGET ${name}-${OROCOS_TARGET}_plugin POST_BUILD
>      COMMAND ${CMAKE_COMMAND} -E copy ${DEBUG_TYPEKITLIB_DIR}
> ${PROJ_BINARY_DIR}/rtt/types
>      COMMENT "Copying ${DEBUG_TYPEKITLIB_DIR} to
> ${PROJ_BINARY_DIR}/rtt/types ")
>  endif()
>  endif(PROJ_BINARY_DIR)
> 

[1] http://www.vtk.org/Bug/view.php?id=10790
<http://www.vtk.org/Bug/view.php?id=10790>
Philippe