Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Non Java projects Proposal"

m (Why is it so hard ?)
(Why is it so hard using Buckminster with non Java projects ?)
Line 8: Line 8:
 
While trying to use Buckminster for both my Java and C++ projects, I realized that Java projects within Eclipse were pretty straightforward but C/C++ projects were much more difficult to manage.
 
While trying to use Buckminster for both my Java and C++ projects, I realized that Java projects within Eclipse were pretty straightforward but C/C++ projects were much more difficult to manage.
  
=== Why is it so hard using Buckminster with non Java projects ? ===
+
=== Why is it so hard to use Buckminster with non Java projects ? ===
  
 
Component materialization is much harder in non Java environments because :
 
Component materialization is much harder in non Java environments because :

Revision as of 10:06, 19 July 2008

< To: Buckminster Project
< To: Helping_Out_(Buckminster)

Note this document is under construction --Guillaume CHATELET

Purpose

While trying to use Buckminster for both my Java and C++ projects, I realized that Java projects within Eclipse were pretty straightforward but C/C++ projects were much more difficult to manage.

Why is it so hard to use Buckminster with non Java projects ?

Component materialization is much harder in non Java environments because :

  • there are no standard way to describe C/C++ projects so you have to write the CSpec file anyway ( contrary to Eclipse Java projects which provides a way to auto generate the CSpec )
  • compiling, testing, your code requires to execute programs from outside ( shell scripts, compiler, unit tests and so forth ).
  • some of the resources you need to materialize are libraries that are only available as zipped url resources.
    • which implies you have to download and unzip them : Buckminster cannot do that for the moment despites its exactly what you expect it to do. So to overcome this issue you have to write ant tasks.

Work flow currently used

The toolchain I created to manage C/C++ projects dependencies is as follows :

  • Create Spec components to describe dependencies
  • Specify actions like build / clean / rebuild
    • those actions have prerequisites pointing to other components (eg: the path to the libTiff include folder)
  • Write ant scripts called from buckminster to
    • retrieve libraries from urls or retrieve files from archives pointed by url
    • execute commands with specific environment variables (eg. calling the compiler with paths to libraries)
  • Create the script to compile the code ( Makefile or Boost Jamfile or SCons file )

Proposal

This page is a proposal to extends Buckminster in order to bring users from the non Java world a better experience.

Executor Actor

This actor would add the possibility to execute programs directly from the CSpec without writing Ant Scripts.

Features

  • Executes programs
  • Sets arguments
    • arguments can refer to prerequisites
  • Sets environment variables for the execution
    • environments variables are key/value pairs
    • environments variables values can refer to prerequisites

Example

<cs:public name="build" actor="executor">
   <cs:actorProperties>
      <cs:exec executable="${gcc}" dir="${buckmintser.home}" />
      <cs:env key="DEBUG" value="1" />
      <cs:env key="LIB_TIFF_INCLUDE" value="${tiff.include}" />
      <cs:env key="LIB_TIFF_LIB" value="${tiff.lib}" />
      <cs:arg value="-j2" />
      <cs:arg value="-I${tiff.include}" />
      <cs:arg value="-L${tiff.lib}" />
   </cs:actorProperties>
   <cs:prerequisites>
      <cs:attribute component="tiff-3.6.1" name="include" alias="tiff.include" />
      <cs:attribute component="tiff-3.6.1" name="lib" alias="tiff.lib" />
      <cs:attribute component="mingw-5.1.4" name="gcc" alias="gcc" />
   </cs:prerequisites>
</cs:public>

Note that the actorProperties section will not allow the exec / var / env elements for the moment.

Syntax

This syntax integrates into Buckminster's CSpec Actions.

TODO : provide specifications

Fetch Actor

This actor is used to materialize resources into the component. I'm still not sure this behavior should be provided by an actor or through the materialization process. It seems the actor can be used at will so it's more flexible than the materialization but this point can be discussed.

Features

  • fetch single or multiple files
  • log to https sites
  • unzip, untar, untargz, untarbz2 files
    • possibility to specify destination directory
    • possibility to filter the archive content
    • keep hierarchy or flatten folders

Example

Back to the top