Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Buckminster dev » Other actors proposal
Other actors proposal [message #21118] Thu, 03 July 2008 06:00 Go to next message
Guillaume Chatelet is currently offline Guillaume ChateletFriend
Messages: 146
Registered: July 2009
Senior Member
Hi everyone,

Buckminster really is a great tool and it's easy to use with eclipse and
java. Buckminster is a good tool to drive a team to continous
integration so I decided to use it as well with our C++ projects. I
managed to get the whole C++ pipe running but the learning curve is
really steep. Here are the steps to accomplish :
-1- Make the buckminster.cspec (detail the dependencies, the actions)
-2- Use prerequisites in the actions to refer to abstract paths of other
components
-3- Use ant to retrieve archives, uncompress them, set a lot of
environnement variables, call the compiler (which is also a component).
-4- Write the makefile ( or compilation instructions )

Ant is a great tool but it's really hard to explain to someone coming
from C++. It's not an easy langage to learn and a lot of action are hard
to do (branching for instance) or impossible to do (loops). Moreover
debugging the execution is a pain in the ass because of the many
langages involved ( buckminster, ant, makefile )

What do you think of a "shell" actor that would just execute a shell
script with the ability to set environement variables as prerequesites ?
To my mind, this would greatly simplify the pipe, the maintenance and
would ease the adoption - learning buckminster is hard but having to
learn buckminster + ant is very hard to my team mates.

It could be fantastic if one could just call the compiler in a
buckminster's action, building the command line within the cspec and
setting the environnement variables in the cspec : less langages, less
code, less debugging, happier developers : )

Tell me what you think about that,
Best regards,
Guillaume
Re: Other actors proposal [message #21141 is a reply to message #21118] Thu, 03 July 2008 06:20 Go to previous messageGo to next message
Thomas Hallgren is currently offline Thomas HallgrenFriend
Messages: 3240
Registered: July 2009
Senior Member
Hi Guillaume,
I've been thinking about a shell actor too. The primary reason why it's
not implemented yet is probably that we, as you say, have been too Java
centric. Java developers use ant and call shell from there.

I'm all for a shell actor. If you would like to have a go at it and
submit a patch, we would be very interested. I promise to be responsive
if you have questions concerning the implementation.

The C++ domain that you're in sounds very interesting. People are asking
for it but so far we haven't had the time or resources to really dive
into it. If you can find some time to share your experience in a bit
more detail (examples and such), I think that would be very valuable to
Buckminster.

Kind Regards,
Thomas Hallgren


Guillaume CHATELET wrote:
> Hi everyone,
>
> Buckminster really is a great tool and it's easy to use with eclipse and
> java. Buckminster is a good tool to drive a team to continous
> integration so I decided to use it as well with our C++ projects. I
> managed to get the whole C++ pipe running but the learning curve is
> really steep. Here are the steps to accomplish :
> -1- Make the buckminster.cspec (detail the dependencies, the actions)
> -2- Use prerequisites in the actions to refer to abstract paths of other
> components
> -3- Use ant to retrieve archives, uncompress them, set a lot of
> environnement variables, call the compiler (which is also a component).
> -4- Write the makefile ( or compilation instructions )
>
> Ant is a great tool but it's really hard to explain to someone coming
> from C++. It's not an easy langage to learn and a lot of action are hard
> to do (branching for instance) or impossible to do (loops). Moreover
> debugging the execution is a pain in the ass because of the many
> langages involved ( buckminster, ant, makefile )
>
> What do you think of a "shell" actor that would just execute a shell
> script with the ability to set environement variables as prerequesites ?
> To my mind, this would greatly simplify the pipe, the maintenance and
> would ease the adoption - learning buckminster is hard but having to
> learn buckminster + ant is very hard to my team mates.
>
> It could be fantastic if one could just call the compiler in a
> buckminster's action, building the command line within the cspec and
> setting the environnement variables in the cspec : less langages, less
> code, less debugging, happier developers : )
>
> Tell me what you think about that,
> Best regards,
> Guillaume
Re: Other actors proposal [message #21512 is a reply to message #21141] Fri, 18 July 2008 13:18 Go to previous messageGo to next message
Guillaume Chatelet is currently offline Guillaume ChateletFriend
Messages: 146
Registered: July 2009
Senior Member
Hi Thomas,

I really wish I had more time to tackle this subject but for now I'm completely drowned under tons of tasks.

Nevertheless I'll try to group here a few ideas that I have.

As I said in my previous post, the work flow for building a C++ project is as follow :
+ Create Spec components to describe dependencies
+ Specify actions ( ant actor for the moment ) to :
=> retrieving files from urls
=> retrieving files from archives pointed by url
=> executing commands with specific environment variables (eg. calling the compiler with paths to libraries)
+ Write ant files
+ Create the script to compile the code ( Makefile or Boost Jamfile or SCons file )

Those steps makes debugging a real puzzle, plus it forces us to rewrite the same ant functions in barely all our components.

We factorized this code by creating scripts in a component named *ant_base_scripts* but it's not really convenient : we have to include those scripts in the prerequisites of buckminster's actions, add an alias to it. Ant then "import" them in our ant scripts to actually perform the actions for the component.

-- Zapping ant

The basic idea is to suppress the ant step because :
+ it's quite hard to learn for non java developers
+ it's quite hard to write ( to my mind XML is not a good language to express code )
+ it's even harder to debug

From this point of view Ant is cluttering and cumbersome.

-- Suggestions

+ adding an "executor" action type to actually execute programs ( batch scripts, compilers, tests, etc... ) possibly programs defined in other component. This action can execute the program with a set of environment variables defined in the CSpec (possibly by referring other components).
+ adding a mean to materialize zipped resources under a component from Buckminster ( no ant call with get, unzip, copy )

eg: I want to retrieve Boost 1.35 ( http://www.boost.org/ )
I'd like to write a Spec component that is able to retrieve this archive http://downloads.sourceforge.net/boost/boost_1_35_0.tar.bz2, uncompress it under it's root ( maybe I want to filter the content of the archive or maybe I want it to be uncompressed under a particular directory ). These files are then accessed through artifacts or groups.

-- What's next
Sure, those few lines are rather insufficient to express the needs but it's a first step.
Thomas, I'm planning to open a wiki ( Google Sites ) to store examples, scenarios, grammars and keep track of comments and suggestions.
I think it's more convenient than the newsgroups to store images, code snippet and other things.
If you agree, I'll try to open it quickly to start the project.

Regards,
Guillaume

Thomas Hallgren wrote:
> Hi Guillaume,
> I've been thinking about a shell actor too. The primary reason why it's
> not implemented yet is probably that we, as you say, have been too Java
> centric. Java developers use ant and call shell from there.
>
> I'm all for a shell actor. If you would like to have a go at it and
> submit a patch, we would be very interested. I promise to be responsive
> if you have questions concerning the implementation.
>
> The C++ domain that you're in sounds very interesting. People are asking
> for it but so far we haven't had the time or resources to really dive
> into it. If you can find some time to share your experience in a bit
> more detail (examples and such), I think that would be very valuable to
> Buckminster.
>
> Kind Regards,
> Thomas Hallgren
>
>
> Guillaume CHATELET wrote:
>> Hi everyone,
>>
>> Buckminster really is a great tool and it's easy to use with eclipse
>> and java. Buckminster is a good tool to drive a team to continous
>> integration so I decided to use it as well with our C++ projects. I
>> managed to get the whole C++ pipe running but the learning curve is
>> really steep. Here are the steps to accomplish :
>> -1- Make the buckminster.cspec (detail the dependencies, the actions)
>> -2- Use prerequisites in the actions to refer to abstract paths of
>> other components
>> -3- Use ant to retrieve archives, uncompress them, set a lot of
>> environnement variables, call the compiler (which is also a component).
>> -4- Write the makefile ( or compilation instructions )
>>
>> Ant is a great tool but it's really hard to explain to someone coming
>> from C++. It's not an easy langage to learn and a lot of action are
>> hard to do (branching for instance) or impossible to do (loops).
>> Moreover debugging the execution is a pain in the ass because of the
>> many langages involved ( buckminster, ant, makefile )
>>
>> What do you think of a "shell" actor that would just execute a shell
>> script with the ability to set environement variables as prerequesites ?
>> To my mind, this would greatly simplify the pipe, the maintenance and
>> would ease the adoption - learning buckminster is hard but having to
>> learn buckminster + ant is very hard to my team mates.
>>
>> It could be fantastic if one could just call the compiler in a
>> buckminster's action, building the command line within the cspec and
>> setting the environnement variables in the cspec : less langages, less
>> code, less debugging, happier developers : )
>>
>> Tell me what you think about that,
>> Best regards,
>> Guillaume
Re: Other actors proposal [message #21538 is a reply to message #21141] Fri, 18 July 2008 13:19 Go to previous messageGo to next message
Guillaume Chatelet is currently offline Guillaume ChateletFriend
Messages: 146
Registered: July 2009
Senior Member
Hi Thomas,

I really wish I had more time to tackle this subject but for now I'm completely drowned under tons of tasks.

Nevertheless I'll try to group here a few ideas that I have.

As I said in my previous post, the work flow for building a C++ project is as follow :
+ Create Spec components to describe dependencies
+ Specify actions ( ant actor for the moment ) to :
=> retrieving files from urls
=> retrieving files from archives pointed by url
=> executing commands with specific environment variables (eg. calling the compiler with paths to libraries)
+ Write ant files
+ Create the script to compile the code ( Makefile or Boost Jamfile or SCons file )

Those steps makes debugging a real puzzle, plus it forces us to rewrite the same ant functions in barely all our components.

We factorized this code by creating scripts in a component named *ant_base_scripts* but it's not really convenient : we have to include those scripts in the prerequisites of buckminster's actions, add an alias to it. Ant then "import" them in our ant scripts to actually perform the actions for the component.

-- Zapping ant

The basic idea is to suppress the ant step because :
+ it's quite hard to learn for non java developers
+ it's quite hard to write ( to my mind XML is not a good language to express code )
+ it's even harder to debug

From this point of view Ant is cluttering and cumbersome.

-- Suggestions

+ adding an "executor" action type to actually execute programs ( batch scripts, compilers, tests, etc... ) possibly programs defined in other component. This action can execute the program with a set of environment variables defined in the CSpec (possibly by referring other components).
+ adding a mean to materialize zipped resources under a component from Buckminster ( no ant call with get, unzip, copy )

eg: I want to retrieve Boost 1.35 ( http://www.boost.org/ )
I'd like to write a Spec component that is able to retrieve this archive http://downloads.sourceforge.net/boost/boost_1_35_0.tar.bz2, uncompress it under it's root ( maybe I want to filter the content of the archive or maybe I want it to be uncompressed under a particular directory ). These files are then accessed through artifacts or groups.

-- What's next
Sure, those few lines are rather insufficient to express the needs but it's a first step.
Thomas, I'm planning to open a wiki ( Google Sites ) to store examples, scenarios, grammars and keep track of comments and suggestions.
I think it's more convenient than the newsgroups to store images, code snippet and other things.
If you agree, I'll try to open it quickly to start the project.

Regards,
Guillaume

Thomas Hallgren wrote:
> Hi Guillaume,
> I've been thinking about a shell actor too. The primary reason why it's
> not implemented yet is probably that we, as you say, have been too Java
> centric. Java developers use ant and call shell from there.
>
> I'm all for a shell actor. If you would like to have a go at it and
> submit a patch, we would be very interested. I promise to be responsive
> if you have questions concerning the implementation.
>
> The C++ domain that you're in sounds very interesting. People are asking
> for it but so far we haven't had the time or resources to really dive
> into it. If you can find some time to share your experience in a bit
> more detail (examples and such), I think that would be very valuable to
> Buckminster.
>
> Kind Regards,
> Thomas Hallgren
>
>
> Guillaume CHATELET wrote:
>> Hi everyone,
>>
>> Buckminster really is a great tool and it's easy to use with eclipse
>> and java. Buckminster is a good tool to drive a team to continous
>> integration so I decided to use it as well with our C++ projects. I
>> managed to get the whole C++ pipe running but the learning curve is
>> really steep. Here are the steps to accomplish :
>> -1- Make the buckminster.cspec (detail the dependencies, the actions)
>> -2- Use prerequisites in the actions to refer to abstract paths of
>> other components
>> -3- Use ant to retrieve archives, uncompress them, set a lot of
>> environnement variables, call the compiler (which is also a component).
>> -4- Write the makefile ( or compilation instructions )
>>
>> Ant is a great tool but it's really hard to explain to someone coming
>> from C++. It's not an easy langage to learn and a lot of action are
>> hard to do (branching for instance) or impossible to do (loops).
>> Moreover debugging the execution is a pain in the ass because of the
>> many langages involved ( buckminster, ant, makefile )
>>
>> What do you think of a "shell" actor that would just execute a shell
>> script with the ability to set environement variables as prerequesites ?
>> To my mind, this would greatly simplify the pipe, the maintenance and
>> would ease the adoption - learning buckminster is hard but having to
>> learn buckminster + ant is very hard to my team mates.
>>
>> It could be fantastic if one could just call the compiler in a
>> buckminster's action, building the command line within the cspec and
>> setting the environnement variables in the cspec : less langages, less
>> code, less debugging, happier developers : )
>>
>> Tell me what you think about that,
>> Best regards,
>> Guillaume
Re: Other actors proposal [message #21580 is a reply to message #21512] Fri, 18 July 2008 13:41 Go to previous messageGo to next message
Thomas Hallgren is currently offline Thomas HallgrenFriend
Messages: 3240
Registered: July 2009
Senior Member
Hi Guillaume,
I think you have very good suggestions. I can understand if you feel
that time is short and you don't have time to implement the "executor"
action right now.

Regarding the wiki, feel free to add things to wiki.eclipse.org. It's
open for anyone who has an Bugzilla account.

We like to use categories to get structure so you can tag the articles
with [[Category:Buckminster]] and [[Category:Buckminster Examples]].

Regards,
Thomas Hallgren


Guillaume CHATELET wrote:
> Hi Thomas,
>
> I really wish I had more time to tackle this subject but for now I'm
> completely drowned under tons of tasks.
>
> Nevertheless I'll try to group here a few ideas that I have.
>
> As I said in my previous post, the work flow for building a C++ project
> is as follow :
> + Create Spec components to describe dependencies
> + Specify actions ( ant actor for the moment ) to :
> => retrieving files from urls
> => retrieving files from archives pointed by url
> => executing commands with specific environment variables (eg. calling
> the compiler with paths to libraries)
> + Write ant files
> + Create the script to compile the code ( Makefile or Boost Jamfile or
> SCons file )
>
> Those steps makes debugging a real puzzle, plus it forces us to rewrite
> the same ant functions in barely all our components.
>
> We factorized this code by creating scripts in a component named
> *ant_base_scripts* but it's not really convenient : we have to include
> those scripts in the prerequisites of buckminster's actions, add an
> alias to it. Ant then "import" them in our ant scripts to actually
> perform the actions for the component.
>
> -- Zapping ant
>
> The basic idea is to suppress the ant step because :
> + it's quite hard to learn for non java developers
> + it's quite hard to write ( to my mind XML is not a good language to
> express code )
> + it's even harder to debug
>
> From this point of view Ant is cluttering and cumbersome.
>
> -- Suggestions
>
> + adding an "executor" action type to actually execute programs ( batch
> scripts, compilers, tests, etc... ) possibly programs defined in other
> component. This action can execute the program with a set of environment
> variables defined in the CSpec (possibly by referring other components).
> + adding a mean to materialize zipped resources under a component from
> Buckminster ( no ant call with get, unzip, copy )
>
> eg: I want to retrieve Boost 1.35 ( http://www.boost.org/ )
> I'd like to write a Spec component that is able to retrieve this archive
> http://downloads.sourceforge.net/boost/boost_1_35_0.tar.bz2, uncompress
> it under it's root ( maybe I want to filter the content of the archive
> or maybe I want it to be uncompressed under a particular directory ).
> These files are then accessed through artifacts or groups.
>
> -- What's next
> Sure, those few lines are rather insufficient to express the needs but
> it's a first step.
> Thomas, I'm planning to open a wiki ( Google Sites ) to store examples,
> scenarios, grammars and keep track of comments and suggestions.
> I think it's more convenient than the newsgroups to store images, code
> snippet and other things.
> If you agree, I'll try to open it quickly to start the project.
>
> Regards,
> Guillaume
>
> Thomas Hallgren wrote:
>> Hi Guillaume,
>> I've been thinking about a shell actor too. The primary reason why
>> it's not implemented yet is probably that we, as you say, have been
>> too Java centric. Java developers use ant and call shell from there.
>>
>> I'm all for a shell actor. If you would like to have a go at it and
>> submit a patch, we would be very interested. I promise to be
>> responsive if you have questions concerning the implementation.
>>
>> The C++ domain that you're in sounds very interesting. People are
>> asking for it but so far we haven't had the time or resources to
>> really dive into it. If you can find some time to share your
>> experience in a bit more detail (examples and such), I think that
>> would be very valuable to Buckminster.
>>
>> Kind Regards,
>> Thomas Hallgren
>>
>>
>> Guillaume CHATELET wrote:
>>> Hi everyone,
>>>
>>> Buckminster really is a great tool and it's easy to use with eclipse
>>> and java. Buckminster is a good tool to drive a team to continous
>>> integration so I decided to use it as well with our C++ projects. I
>>> managed to get the whole C++ pipe running but the learning curve is
>>> really steep. Here are the steps to accomplish :
>>> -1- Make the buckminster.cspec (detail the dependencies, the actions)
>>> -2- Use prerequisites in the actions to refer to abstract paths of
>>> other components
>>> -3- Use ant to retrieve archives, uncompress them, set a lot of
>>> environnement variables, call the compiler (which is also a component).
>>> -4- Write the makefile ( or compilation instructions )
>>>
>>> Ant is a great tool but it's really hard to explain to someone coming
>>> from C++. It's not an easy langage to learn and a lot of action are
>>> hard to do (branching for instance) or impossible to do (loops).
>>> Moreover debugging the execution is a pain in the ass because of the
>>> many langages involved ( buckminster, ant, makefile )
>>>
>>> What do you think of a "shell" actor that would just execute a shell
>>> script with the ability to set environement variables as prerequesites ?
>>> To my mind, this would greatly simplify the pipe, the maintenance and
>>> would ease the adoption - learning buckminster is hard but having to
>>> learn buckminster + ant is very hard to my team mates.
>>>
>>> It could be fantastic if one could just call the compiler in a
>>> buckminster's action, building the command line within the cspec and
>>> setting the environnement variables in the cspec : less langages,
>>> less code, less debugging, happier developers : )
>>>
>>> Tell me what you think about that,
>>> Best regards,
>>> Guillaume
Re: Other actors proposal [message #21626 is a reply to message #21580] Sat, 19 July 2008 12:30 Go to previous messageGo to next message
Guillaume Chatelet is currently offline Guillaume ChateletFriend
Messages: 146
Registered: July 2009
Senior Member
Hi Thomas,

As you suggested, I started some pages on the wiki :
http://wiki.eclipse.org/Non_Java_projects_Proposal

It's still under construction for the moment. I also placed a link to
this page at http://wiki.eclipse.org/Helping_Out_(Buckminster) so other
people could contribute.

At the same time I downloaded Buckminster sources and had a look to the
Ant actor. I started a plugin : org.eclipse.buckminster.executor but as
I was looking at org.eclipse.buckminster.ant plugin I noticed that a
"Build Script" extension point was proposed. Do you think I should
extend org.eclipse.buckminster.ant or create another plugin ?

Have you got more technical documentation about Buckminster so I could
dive into the code more easily ?

Regards,
Guillaume

Thomas Hallgren a écrit :
> Hi Guillaume,
> I think you have very good suggestions. I can understand if you feel
> that time is short and you don't have time to implement the "executor"
> action right now.
>
> Regarding the wiki, feel free to add things to wiki.eclipse.org. It's
> open for anyone who has an Bugzilla account.
>
> We like to use categories to get structure so you can tag the articles
> with [[Category:Buckminster]] and [[Category:Buckminster Examples]].
>
> Regards,
> Thomas Hallgren
>
>
> Guillaume CHATELET wrote:
>> Hi Thomas,
>>
>> I really wish I had more time to tackle this subject but for now I'm
>> completely drowned under tons of tasks.
>>
>> Nevertheless I'll try to group here a few ideas that I have.
>>
>> As I said in my previous post, the work flow for building a C++
>> project is as follow :
>> + Create Spec components to describe dependencies
>> + Specify actions ( ant actor for the moment ) to :
>> => retrieving files from urls
>> => retrieving files from archives pointed by url
>> => executing commands with specific environment variables (eg.
>> calling the compiler with paths to libraries)
>> + Write ant files
>> + Create the script to compile the code ( Makefile or Boost Jamfile or
>> SCons file )
>>
>> Those steps makes debugging a real puzzle, plus it forces us to
>> rewrite the same ant functions in barely all our components.
>>
>> We factorized this code by creating scripts in a component named
>> *ant_base_scripts* but it's not really convenient : we have to include
>> those scripts in the prerequisites of buckminster's actions, add an
>> alias to it. Ant then "import" them in our ant scripts to actually
>> perform the actions for the component.
>>
>> -- Zapping ant
>>
>> The basic idea is to suppress the ant step because :
>> + it's quite hard to learn for non java developers
>> + it's quite hard to write ( to my mind XML is not a good language to
>> express code )
>> + it's even harder to debug
>>
>> From this point of view Ant is cluttering and cumbersome.
>>
>> -- Suggestions
>>
>> + adding an "executor" action type to actually execute programs (
>> batch scripts, compilers, tests, etc... ) possibly programs defined in
>> other component. This action can execute the program with a set of
>> environment variables defined in the CSpec (possibly by referring
>> other components).
>> + adding a mean to materialize zipped resources under a component from
>> Buckminster ( no ant call with get, unzip, copy )
>>
>> eg: I want to retrieve Boost 1.35 ( http://www.boost.org/ )
>> I'd like to write a Spec component that is able to retrieve this
>> archive http://downloads.sourceforge.net/boost/boost_1_35_0.tar.bz2,
>> uncompress it under it's root ( maybe I want to filter the content of
>> the archive or maybe I want it to be uncompressed under a particular
>> directory ). These files are then accessed through artifacts or groups.
>>
>> -- What's next
>> Sure, those few lines are rather insufficient to express the needs but
>> it's a first step.
>> Thomas, I'm planning to open a wiki ( Google Sites ) to store
>> examples, scenarios, grammars and keep track of comments and suggestions.
>> I think it's more convenient than the newsgroups to store images, code
>> snippet and other things.
>> If you agree, I'll try to open it quickly to start the project.
>>
>> Regards,
>> Guillaume
>>
>> Thomas Hallgren wrote:
>>> Hi Guillaume,
>>> I've been thinking about a shell actor too. The primary reason why
>>> it's not implemented yet is probably that we, as you say, have been
>>> too Java centric. Java developers use ant and call shell from there.
>>>
>>> I'm all for a shell actor. If you would like to have a go at it and
>>> submit a patch, we would be very interested. I promise to be
>>> responsive if you have questions concerning the implementation.
>>>
>>> The C++ domain that you're in sounds very interesting. People are
>>> asking for it but so far we haven't had the time or resources to
>>> really dive into it. If you can find some time to share your
>>> experience in a bit more detail (examples and such), I think that
>>> would be very valuable to Buckminster.
>>>
>>> Kind Regards,
>>> Thomas Hallgren
>>>
>>>
>>> Guillaume CHATELET wrote:
>>>> Hi everyone,
>>>>
>>>> Buckminster really is a great tool and it's easy to use with eclipse
>>>> and java. Buckminster is a good tool to drive a team to continous
>>>> integration so I decided to use it as well with our C++ projects. I
>>>> managed to get the whole C++ pipe running but the learning curve is
>>>> really steep. Here are the steps to accomplish :
>>>> -1- Make the buckminster.cspec (detail the dependencies, the actions)
>>>> -2- Use prerequisites in the actions to refer to abstract paths of
>>>> other components
>>>> -3- Use ant to retrieve archives, uncompress them, set a lot of
>>>> environnement variables, call the compiler (which is also a component).
>>>> -4- Write the makefile ( or compilation instructions )
>>>>
>>>> Ant is a great tool but it's really hard to explain to someone
>>>> coming from C++. It's not an easy langage to learn and a lot of
>>>> action are hard to do (branching for instance) or impossible to do
>>>> (loops). Moreover debugging the execution is a pain in the ass
>>>> because of the many langages involved ( buckminster, ant, makefile )
>>>>
>>>> What do you think of a "shell" actor that would just execute a shell
>>>> script with the ability to set environement variables as
>>>> prerequesites ?
>>>> To my mind, this would greatly simplify the pipe, the maintenance
>>>> and would ease the adoption - learning buckminster is hard but
>>>> having to learn buckminster + ant is very hard to my team mates.
>>>>
>>>> It could be fantastic if one could just call the compiler in a
>>>> buckminster's action, building the command line within the cspec and
>>>> setting the environnement variables in the cspec : less langages,
>>>> less code, less debugging, happier developers : )
>>>>
>>>> Tell me what you think about that,
>>>> Best regards,
>>>> Guillaume
Re: Other actors proposal [message #21671 is a reply to message #21626] Sat, 19 July 2008 15:35 Go to previous message
Thomas Hallgren is currently offline Thomas HallgrenFriend
Messages: 3240
Registered: July 2009
Senior Member
Hi Guillaume,

Guillaume CHATELET wrote:
> Hi Thomas,
>
> As you suggested, I started some pages on the wiki :
> http://wiki.eclipse.org/Non_Java_projects_Proposal
>
Looks very good.

> It's still under construction for the moment. I also placed a link to
> this page at http://wiki.eclipse.org/Helping_Out_(Buckminster) so
> other people could contribute.
>
Good idea.

> At the same time I downloaded Buckminster sources and had a look to
> the Ant actor. I started a plugin : org.eclipse.buckminster.executor
> but as I was looking at org.eclipse.buckminster.ant plugin I noticed
> that a "Build Script" extension point was proposed. Do you think I
> should extend org.eclipse.buckminster.ant or create another plugin ?
>
I think it's better to create a new plug-in so that no unnecessary
dependency is to ant is implied.

> Have you got more technical documentation about Buckminster so I could
> dive into the code more easily ?
>
No sorry. All we got at this time is on the wiki.

Regards,
Thomas Hallgren

> Regards,
> Guillaume
>
> Thomas Hallgren a écrit :
>> Hi Guillaume,
>> I think you have very good suggestions. I can understand if you feel
>> that time is short and you don't have time to implement the
>> "executor" action right now.
>>
>> Regarding the wiki, feel free to add things to wiki.eclipse.org. It's
>> open for anyone who has an Bugzilla account.
>>
>> We like to use categories to get structure so you can tag the
>> articles with [[Category:Buckminster]] and [[Category:Buckminster
>> Examples]].
>>
>> Regards,
>> Thomas Hallgren
>>
>>
>> Guillaume CHATELET wrote:
>>> Hi Thomas,
>>>
>>> I really wish I had more time to tackle this subject but for now I'm
>>> completely drowned under tons of tasks.
>>>
>>> Nevertheless I'll try to group here a few ideas that I have.
>>>
>>> As I said in my previous post, the work flow for building a C++
>>> project is as follow :
>>> + Create Spec components to describe dependencies
>>> + Specify actions ( ant actor for the moment ) to :
>>> => retrieving files from urls
>>> => retrieving files from archives pointed by url
>>> => executing commands with specific environment variables (eg.
>>> calling the compiler with paths to libraries)
>>> + Write ant files
>>> + Create the script to compile the code ( Makefile or Boost Jamfile
>>> or SCons file )
>>>
>>> Those steps makes debugging a real puzzle, plus it forces us to
>>> rewrite the same ant functions in barely all our components.
>>>
>>> We factorized this code by creating scripts in a component named
>>> *ant_base_scripts* but it's not really convenient : we have to
>>> include those scripts in the prerequisites of buckminster's actions,
>>> add an alias to it. Ant then "import" them in our ant scripts to
>>> actually perform the actions for the component.
>>>
>>> -- Zapping ant
>>>
>>> The basic idea is to suppress the ant step because :
>>> + it's quite hard to learn for non java developers
>>> + it's quite hard to write ( to my mind XML is not a good language
>>> to express code )
>>> + it's even harder to debug
>>>
>>> From this point of view Ant is cluttering and cumbersome.
>>>
>>> -- Suggestions
>>>
>>> + adding an "executor" action type to actually execute programs (
>>> batch scripts, compilers, tests, etc... ) possibly programs defined
>>> in other component. This action can execute the program with a set
>>> of environment variables defined in the CSpec (possibly by referring
>>> other components).
>>> + adding a mean to materialize zipped resources under a component
>>> from Buckminster ( no ant call with get, unzip, copy )
>>>
>>> eg: I want to retrieve Boost 1.35 ( http://www.boost.org/ )
>>> I'd like to write a Spec component that is able to retrieve this
>>> archive http://downloads.sourceforge.net/boost/boost_1_35_0.tar.bz2,
>>> uncompress it under it's root ( maybe I want to filter the content
>>> of the archive or maybe I want it to be uncompressed under a
>>> particular directory ). These files are then accessed through
>>> artifacts or groups.
>>>
>>> -- What's next
>>> Sure, those few lines are rather insufficient to express the needs
>>> but it's a first step.
>>> Thomas, I'm planning to open a wiki ( Google Sites ) to store
>>> examples, scenarios, grammars and keep track of comments and
>>> suggestions.
>>> I think it's more convenient than the newsgroups to store images,
>>> code snippet and other things.
>>> If you agree, I'll try to open it quickly to start the project.
>>>
>>> Regards,
>>> Guillaume
>>>
>>> Thomas Hallgren wrote:
>>>> Hi Guillaume,
>>>> I've been thinking about a shell actor too. The primary reason why
>>>> it's not implemented yet is probably that we, as you say, have been
>>>> too Java centric. Java developers use ant and call shell from there.
>>>>
>>>> I'm all for a shell actor. If you would like to have a go at it and
>>>> submit a patch, we would be very interested. I promise to be
>>>> responsive if you have questions concerning the implementation.
>>>>
>>>> The C++ domain that you're in sounds very interesting. People are
>>>> asking for it but so far we haven't had the time or resources to
>>>> really dive into it. If you can find some time to share your
>>>> experience in a bit more detail (examples and such), I think that
>>>> would be very valuable to Buckminster.
>>>>
>>>> Kind Regards,
>>>> Thomas Hallgren
>>>>
>>>>
>>>> Guillaume CHATELET wrote:
>>>>> Hi everyone,
>>>>>
>>>>> Buckminster really is a great tool and it's easy to use with
>>>>> eclipse and java. Buckminster is a good tool to drive a team to
>>>>> continous integration so I decided to use it as well with our C++
>>>>> projects. I managed to get the whole C++ pipe running but the
>>>>> learning curve is really steep. Here are the steps to accomplish :
>>>>> -1- Make the buckminster.cspec (detail the dependencies, the actions)
>>>>> -2- Use prerequisites in the actions to refer to abstract paths of
>>>>> other components
>>>>> -3- Use ant to retrieve archives, uncompress them, set a lot of
>>>>> environnement variables, call the compiler (which is also a
>>>>> component).
>>>>> -4- Write the makefile ( or compilation instructions )
>>>>>
>>>>> Ant is a great tool but it's really hard to explain to someone
>>>>> coming from C++. It's not an easy langage to learn and a lot of
>>>>> action are hard to do (branching for instance) or impossible to do
>>>>> (loops). Moreover debugging the execution is a pain in the ass
>>>>> because of the many langages involved ( buckminster, ant, makefile )
>>>>>
>>>>> What do you think of a "shell" actor that would just execute a
>>>>> shell script with the ability to set environement variables as
>>>>> prerequesites ?
>>>>> To my mind, this would greatly simplify the pipe, the maintenance
>>>>> and would ease the adoption - learning buckminster is hard but
>>>>> having to learn buckminster + ant is very hard to my team mates.
>>>>>
>>>>> It could be fantastic if one could just call the compiler in a
>>>>> buckminster's action, building the command line within the cspec
>>>>> and setting the environnement variables in the cspec : less
>>>>> langages, less code, less debugging, happier developers : )
>>>>>
>>>>> Tell me what you think about that,
>>>>> Best regards,
>>>>> Guillaume
>
>
Previous Topic:Automated build / test stuff for Buckminster
Next Topic:[buckminster-dev] Hello XML World Example error
Goto Forum:
  


Current Time: Tue Mar 19 09:46:52 GMT 2024

Powered by FUDForum. Page generated in 0.05708 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top