Hi devs,
What about moving the typekit/ directory, which is automatically generated
by typegen when using the orocos_typegen_headers macro, into the 'build/'
directory?
It would allow to easily clear the sources by just removing "build/", and
then it would have a clearer behaviour when invoking "autoproj rebuild
mypackage", which will also regenerate the typekit.
Charles.
What about typegen generating typekit/ in the build/ folder?
On 10/04/2012 08:31 AM, Charles Lesire-Cabaniols wrote:
> Hi devs,
>
> What about moving the typekit/ directory, which is automatically
> generated by typegen when using the orocos_typegen_headers macro, into
> the 'build/' directory?
>
> It would allow to easily clear the sources by just removing "build/",
> and then it would have a clearer behaviour when invoking "autoproj
> rebuild mypackage", which will also regenerate the typekit.
The rebuilding part could also be achieved by creating an orocos_package
package type in autoproj which would simply add the removal of typekit/
as a cleanup step.
This having typekit/ "public" is also a problem to use opaques, as
opaques require some user code. In orogen, the private part is
generated in .orogen and the user part in typekit/ ...
What about typegen generating typekit/ in the build/ folder?
2012/10/4 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>
> On 10/04/2012 08:31 AM, Charles Lesire-Cabaniols wrote:
>
>> Hi devs,
>>
>> What about moving the typekit/ directory, which is automatically
>> generated by typegen when using the orocos_typegen_headers macro, into the
>> 'build/' directory?
>>
>> It would allow to easily clear the sources by just removing "build/", and
>> then it would have a clearer behaviour when invoking "autoproj rebuild
>> mypackage", which will also regenerate the typekit.
>>
> The rebuilding part could also be achieved by creating an orocos_package
> package type in autoproj which would simply add the removal of typekit/ as
> a cleanup step.
>
Not so easy... as it prevents users to create a typekit folder by their
own... or would you have a way in autoproj to check whether typekit/ has
been created by typegen or not?
>
> This having typekit/ "public" is also a problem to use opaques, as opaques
> require some user code. In orogen, the private part is generated in
> .orogen and the user part in typekit/ ...
>
> --
> Sylvain Joyeux (Dr.Ing.)
> Senior Researcher
>
> Space & Security Robotics
> Underwater Robotics
>
> !!! Achtung, neue Telefonnummer!!!
>
> Standort Bremen:
> DFKI GmbH
> Robotics Innovation Center
> Robert-Hooke-Straße 5
> 28359 Bremen, Germany
>
> Phone: +49 (0)421 178-454136
> Fax: +49 (0)421 218-454150
> E-Mail: robotik [..] ...
>
> Weitere Informationen: http://www.dfki.de/robotik
> ------------------------------**------------------------------**
> -----------
> Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
> Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
> Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
> (Vorsitzender) Dr. Walter Olthoff
> Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
> Amtsgericht Kaiserslautern, HRB 2313
> Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
> USt-Id.Nr.: DE 148646973
> Steuernummer: 19/673/0060/3
> ------------------------------**------------------------------**
> -----------
>
>
What about typegen generating typekit/ in the build/ folder?
On Thu, Oct 4, 2012 at 8:31 AM, Charles Lesire-Cabaniols <
charles [dot] lesire [..] ...> wrote:
> Hi devs,
>
> What about moving the typekit/ directory, which is automatically generated
> by typegen when using the orocos_typegen_headers macro, into the 'build/'
> directory?
>
> It would allow to easily clear the sources by just removing "build/", and
> then it would have a clearer behaviour when invoking "autoproj rebuild
> mypackage", which will also regenerate the typekit.
We use this directory in the (older) ROS build system to 'import' typekits
from packages. In 'old' ROS, each package had a 'bin', 'lib' and/or
'typekit' directory with the final build results. The new ros build system
(catkin) has also a make install step, but switching to this system seems
to early to me, since they are changing it with each release...
It would be necessary to reform the component and plugin loaders such that
they find the typekits in the new locations as well, staying compatible
with the old locations. This might also influence the contents of the .pc
files, which we also use. So some cmake logic would need modifications as
well.
Peter