Home » Eclipse Projects » Buckminster dev » Other actors proposal
| Other actors proposal [message #21118] |
Thu, 03 July 2008 02:00  |
Eclipse User |
|
|
|
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 02:20  |
| Eclipse User |
|
|
|
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 09:18 |
| Eclipse User |
|
|
|
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 09:19 |
| Eclipse User |
|
|
|
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 09:41 |
| Eclipse User |
|
|
|
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 08:30 |
| Eclipse User |
|
|
|
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 11:35 |
| Eclipse User |
|
|
|
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
>
>
|
|
|
Goto Forum:
Current Time: Thu Mar 13 13:58:32 EDT 2025
Powered by FUDForum. Page generated in 0.04827 seconds |
Home