bug about PCL or NodeStateManager.

Frederico Cadete frederico at cadete.eu
Wed Jun 8 10:44:35 EDT 2016

On Wed, Jun 8, 2016 at 1:21 PM, Frederico Cadete <frederico at cadete.eu> wrote:
> Hello,
> On Wed, Jun 8, 2016 at 12:43 PM, Andersson, Gunnar
> <gunnar.x.andersson at volvocars.com> wrote:
>> If something cannot be done automatically I think another common
>> way is to provide a flag given to ./configure or cmake instead of a
>> .cfg file right?  If a flag exists I think it would be a more natural step
>> for build script to use that then to modify config files.
>> Does anyone else have a good proposal how to do this?
>> If anyone else with long experience in autoconf/automake
>> can take a look and suggest a patch, that would be great too.
>> (it's also about learning best practices for other components)
> This .cfg file is already being parsed by the autotools so it should
> be very easy to adapt.
> I am also interested in 64-bit/32-bit builds without much
> configuration so I can have a look.

I give up, autotools wins the day!

The correct solution would be to have the .in file refer to the
"@libdir@" variable.
The problem is that when this variable is expanded by AC_CONFIG_FILES,
it will result in "${exec_prefix}/lib", which is not conformat to the
expected format of the .cfg file.

I have tried setting up a recursive or two-pass substitution in the
autotools scripts,
but it got very kludgy very fast. Given the complexity in autotools it
may really be
that the simpler solution is expecting the user (or the Yocto recipe)
to edit the .cfg

The thing that baffles me is that I don't find a solution to the root
problem in other
projects. If anyone has experience with autotools and can help, please
give your input :)

Best regards,

More information about the genivi-projects mailing list