RE: [dsdp-tcf-dev] TCF C agent build system

["Tarassov, Eugene" <eugene.tarassov@xxxxxxxxxxxxx>]

Hi Alexis,

Adding support for autotools-based build might be a good idea as long as it is done on top of existing code as one of build options, without breaking existing build.
I'm not an expert in autotools, so if you can contribute initial implementation it would be great.
Adding autotools-based build into Eclipse repository might require legal checks - Eclipse licensing is not compatible with GPL.

And I agree with Doug, using CMake seems to be a better approach since we need a cross-platform build.

Regards,
Eugene.

-----Original Message-----
From: dsdp-tcf-dev-bounces@xxxxxxxxxxx [mailto:dsdp-tcf-dev-bounces@xxxxxxxxxxx] On Behalf Of Doug Schaefer
Sent: Tuesday, July 20, 2010 12:58 PM
To: DSDP TCF dev list
Subject: Re: [dsdp-tcf-dev] TCF C agent build system

On Tue, Jul 20, 2010 at 3:49 PM, Alexis Hallé <alexis.halle@xxxxxxxxxx> wrote:
> Hi,
>
> I am working for École Polytechnique de Montréal. We use the TCF 
> reference agent as a basis for our remote tracing system, lttng-agent, 
> which is implemented as a plugin for the agent. We are trying to 
> streamline our own build process, which currently depends on the 
> actual source code of the TCF agent. We are trying to get rid of this 
> dependency but it is currently impossible, as the headers required for 
> plugin development are not installed as part of make install. This 
> looks like a bug to me. If the agent exposes an interface to plugins, 
> shouldn't it install the relevant headers? I can open a bug report 
> about that, but I would also like to open a more general discussion on 
> the TCF agent build system.
>
> The current build system allows (partial) installation but not 
> uninstallation. It uses uncommon make variables to specify install 
> location. The plugins path is hardcoded at compile time. The point I 
> am trying to make is that the current system mostly works, but the 
> process is not what linux users expect, and in our opinion it's 
> hurting usability. I am not saying it's bad, just that it could be 
> better.
>
> We think an autotools-based build system would solve these problems 
> and provide a solid base for the future. We believe that using a 
> somewhat "standard" build system would make the installation process 
> easier for users. Services could be enabled or disabled via the 
> --enable-xxx or --disable-xxx switches of the configure script. The 
> plugins subsystem could be enabled or disabled in the same way. It 
> would manage the build options for the different target operating 
> systems and most importantly allow easy installation, uninstallation, 
> release or packaging of files in a way that is consistent with other 
> major open-source projects. I think consistency is the keyword here, 
> and autotools is a tried and tested solution.
>
> I'd like to hear your opinion on this matter. As the TCF agent is an 
> important piece of our own puzzle, we would be willing to help with 
> the conversion of the build system, if you think it is a good idea.

I've personally become a huge fan of CMake. It's being used by more and more open source projects and includes support for Microsoft Visual C++ that autotools does not. And we should be able to make it work for any OS like vxWorks. I just did some work to get it to support building Android static libraries (which I will be blogging about in the next couple of days).

Doug.
_______________________________________________
dsdp-tcf-dev mailing list
dsdp-tcf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-tcf-dev