Home » Archived » Buckminster » targetPlatforms, workspaces and build output for dummys
| targetPlatforms, workspaces and build output for dummys [message #552084] |
Tue, 10 August 2010 18:24  |
 Miles Parker
Messages: 1341
Registered: July 2009 |
Senior Member |
|
|
I feel silly even asking this, but I realized that I'm still having a bit of trouble mapping my experience with other building approaches to buckminster way. To keep it simple let's talk about regular IDE based Eclipse development. There there are three locations to deal with:
1. target platform, or the set of (immutable as far as PDE build is concerned) features and plugins I'm *basing* my build on.
2. workspace, or the set of features and plugins that I'm developing my build *for*.
3. runtime target platform, or the set of features and plugins that I'll be launching my Eclipse Runtime *with*. This is basically (2) plus large parts (say runtime) of (1).
4. deployment p2 site, which is basically (2), plus minimal pieces in (1) that are not being made available from other P2 sites.
5. deployment RCP/IDE application, which is basically (3) plus perhaps a few other bits.
So it is clear what covers 1 and 2 above, but I'm not actually clear on what is happening with the build output (3,4 and 5) in a scenario where one has builds with dependencies on each other. That is where you want to create a build-A 3 that is then used as a build-B 1.
That's because it seems that some of the results of my build are ending up in the target platform, not an output directory. I was expecting the target platform that I've generated form a previous build to stay pristine, but the I realized if I define a p2 searchPath in my build-B, that the results of that will actually be installed into build-A 3.
I think that in order to achieve what I want, that is a complete clean chain of builds, I need to actually copy the target platform into a newly defined build-B targetPlatform, correct?
|
|
|
| Re: targetPlatforms, workspaces and build output for dummys [message #552205 is a reply to message #552084] |
Wed, 11 August 2010 08:47  |
Johannes Utzig
Messages: 329
Registered: July 2009 |
Senior Member |
|
|
Hi Miles,
please see comments below
Am 10.08.2010 20:24, schrieb Miles Parker:
> That's because it seems that some of the results of my build are ending
> up in the target platform, not an output directory. I was expecting the
> target platform that I've generated form a previous build to stay
> pristine, but the I realized if I define a p2 searchPath in my build-B,
> that the results of that will actually be installed into build-A 3.
>
Yes, this is new in Buckminster 3.6. The default is: binary artifacts go
into the target platform, source goes into the workspace. I think this
default makes a lot of sense since it's how you develop in eclipse. You
don't import your target platform into your workspace.
It's however a default and can be adjusted with an MSPEC.
> I think that in order to achieve what I want, that is a complete clean
> chain of builds, I need to actually copy the target platform into a
> newly defined build-B targetPlatform, correct?
If your other builds create p2 repositories, why don't you just create a
..target file that points to these freshly build p2 repositories +
everything else you need and activate that as your target platform?
Best regards,
Johannes
|
|
|
| Re: targetPlatforms, workspaces and build output for dummys [message #552318 is a reply to message #552205] |
Wed, 11 August 2010 17:26 |
Miles Parker
Messages: 1341
Registered: July 2009 |
Senior Member |
|
|
Hi Thomas,
Also below..
| Johannes Utzig wrote on Wed, 11 August 2010 04:47 | Am 10.08.2010 20:24, schrieb Miles Parker:
> That's because it seems that some of the results of my build are ending
> up in the target platform, not an output directory. I was expecting the
> target platform that I've generated form a previous build to stay
> pristine, but the I realized if I define a p2 searchPath in my build-B,
> that the results of that will actually be installed into build-A 3.
>
It's however a default and can be adjusted with an MSPEC.
|
Yes, it does seem to make a lot of sense to do things that way by default. I've discovered that interestingly it is not always cut and dried what to install in target platform and what in workspace. For example, sometimes those ugly ducklings show up that create trouble for platform so you don't want to install them, but you need them for build to succeed. And on the other hand, you sometimes want to include some stuff from the target platform even in your p2 site (i.e. not just product).
But I'm wondering more if it wouldn't make sense to have an explicit sandbox for the (3) part. (Just what we need, more artifacts!  ) This would essentially mean making build-target into a first class citizen of the build chain. So at any stage of the game you'd have:
TP1(platform) + WS1(null) -> B1 (e.g. RCP Target)
B1 + WS2 -> B2 (e.g. my p2 site)
(B1 + B2.p2) + WS3 -> TP3 (e.g. my RCP app)
(TP3 + Bx.p2) + WS4(null) -> TP4 (e.g. my enhanced RCP app)
| Quote: | > I think that in order to achieve what I want, that is a complete clean
> chain of builds, I need to actually copy the target platform into a
> newly defined build-B targetPlatform, correct?
If your other builds create p2 repositories, why don't you just create a
..target file that points to these freshly build p2 repositories +
everything else you need and activate that as your target platform?
|
I think that would be simpler for sure, and it's what I am doing to create my basic targets for my local setup. That is for example I create a target platform with Eclipse Platform, Some Eclipse Modeling tools like (EMF XPand, etc..) and create a Hudson job for it. So rather than have to build that every time, I want to define it and have it ready made for when I need it. Then I use that as input for my actual site or product build(s). Here my target platform is the set of dependencies that I need to build my p2.site or product
The copying obviously isn't a big deal but it's nice to be able to do everything from Buckminster proper. How would I set up an mspec to accomplish that same thing? I'm not sure I really get the mspec idea yet..
And I actually then realized that I can't use the TP approach for my p2.site build because I can't do a separate build in Eclipse hosted hudson. So there I just bring in everything at once and I'm following how other projects have done it which is using a cspec. I'm really not getting when to use a cpec to implicitly create a tp vs. when to explicitly create one with importtargetdef, but my thinking is that it is ultimitly better to have this in cspec as it puts all of the dependency info in one form, which seems like the ultimate goal. And I was thinking that there was some magic to using buckminster cpec mechanism to resolve everything that went beyond what the target platform does.
At this point my brain is pretty much jello..
|
|
|
| Re: targetPlatforms, workspaces and build output for dummys [message #552393 is a reply to message #552318] |
Thu, 12 August 2010 04:39 |
|
Hi Miles,
Some comments inline...
On 08/11/2010 07:26 PM, Miles Parker wrote:
> Hi Thomas,
>
> Also below..
>
> Johannes Utzig wrote on Wed, 11 August 2010 04:47
>> Am 10.08.2010 20:24, schrieb Miles Parker:
>> > That's because it seems that some of the results of my build are ending
>> > up in the target platform, not an output directory. I was expecting the
>> > target platform that I've generated form a previous build to stay
>> > pristine, but the I realized if I define a p2 searchPath in my build-B,
>> > that the results of that will actually be installed into build-A 3.
>> >
>>
>> It's however a default and can be adjusted with an MSPEC.
>
>
> Yes, it does seem to make a lot of sense to do things that way by
> default. I've discovered that interestingly it is not always cut and
> dried what to install in target platform and what in workspace. For
> example, sometimes those ugly ducklings show up that create trouble for
> platform so you don't want to install them, but you need them for build
> to succeed. And on the other hand, you sometimes want to include some
> stuff from the target platform even in your p2 site (i.e. not just
> product).
>
> But I'm wondering more if it wouldn't make sense to have an explicit
> sandbox for the (3) part. (Just what we need, more artifacts! :)) This
> would essentially mean making build-target into a first class citizen of
> the build chain. So at any stage of the game you'd have:
>
> TP1(platform) + WS1(null) -> B1 (e.g. RCP Target)
> B1 + WS2 -> B2 (e.g. my p2 site)
> (B1 + B2.p2) + WS3 -> TP3 (e.g. my RCP app)
> (TP3 + Bx.p2) + WS4(null) -> TP4 (e.g. my enhanced RCP app)
>
I think this is a bad idea since the build target lacks meta-data. That makes it a hard to maintain and pass around. A
better approach is to use p2 repositories everywhere, i.e. replace the TP with a p2 repository at all times and let the
TP become a black box that is internal to each build.
Build A consumes sources from SCM's and p2 repositories. It produces a p2 repository.
Build B consumes sources from SCM's and p2 repositories (including the one produced by build A). It produces a p2
repository.
Build C ...
This can be made very efficient by use of composite repositories (they simply reference their contained repositories, so
no copying needed) and provisioning the TP is fairly quick when the repositories are local.
The advantage of this approach is that you make the boundaries of each build very distinct. The API becomes the SCM and
p2. No need to bother with the fact that TP's are used at all. And the p2 repository is generally the desired output
anyway so there's no overhead either.
> Quote:
>> > I think that in order to achieve what I want, that is a complete clean
>> > chain of builds, I need to actually copy the target platform into a
>> > newly defined build-B targetPlatform, correct?
>>
>> If your other builds create p2 repositories, why don't you just create
>> a ..target file that points to these freshly build p2 repositories +
>> everything else you need and activate that as your target platform?
>
>
> I think that would be simpler for sure, and it's what I am doing to
> create my basic targets for my local setup. That is for example I create
> a target platform with Eclipse Platform, Some Eclipse Modeling tools
> like (EMF XPand, etc..) and create a Hudson job for it. So rather than
> have to build that every time, I want to define it and have it ready
> made for when I need it. Then I use that as input for my actual site or
> product build(s). Here my target platform is the set of dependencies
> that I need to build my p2.site or product
>
The difficulty with this is that it's hard to extend the TP for each individual build. You very quickly run into a
situation where the TP must be copied first (in full) and then extended. As soon as you get to that point it would be
better to create the TP from scratch form a local repository.
> The copying obviously isn't a big deal but it's nice to be able to do
> everything from Buckminster proper. How would I set up an mspec to
> accomplish that same thing? I'm not sure I really get the mspec idea yet..
>
> And I actually then realized that I can't use the TP approach for my
> p2.site build because I can't do a separate build in Eclipse hosted
> hudson. So there I just bring in everything at once and I'm following
> how other projects have done it which is using a cspec. I'm really not
> getting when to use a cpec to implicitly create a tp vs. when to
> explicitly create one with importtargetdef, but my thinking is that it
> is ultimitly better to have this in cspec as it puts all of the
> dependency info in one form, which seems like the ultimate goal. And I
> was thinking that there was some magic to using buckminster cpec
> mechanism to resolve everything that went beyond what the target
> platform does.
>
The magic is there (well parts of it anyway), you just have to abandon the TP as the vehicle and use p2 repositories
instead.
HTH,
- thomas
|
|
|
| Re: targetPlatforms, workspaces and build output for dummys [message #552620 is a reply to message #552393] |
Thu, 12 August 2010 21:19 |
Miles Parker
Messages: 1341
Registered: July 2009 |
Senior Member |
|
|
| Thomas Hallgren wrote on Thu, 12 August 2010 00:39 |
On 08/11/2010 07:26 PM, Miles Parker wrote:
> TP1(platform) + WS1(null) -> B1 (e.g. RCP Target)
> B1 + WS2 -> B2 (e.g. my p2 site)
> (B1 + B2.p2) + WS3 -> TP3 (e.g. my RCP app)
> (TP3 + Bx.p2) + WS4(null) -> TP4 (e.g. my enhanced RCP app)
>
I think this is a bad idea since the build target lacks meta-data. That makes it a hard to maintain and pass around. A
better approach is to use p2 repositories everywhere, i.e. replace the TP with a p2 repository at all times and let the
TP become a black box that is internal to each build.
|
Yes, I think that makes a ton of sense, and it's the approach I'm coming to. The only exception is for the base builds that I know won't change frequently, i.e. I have a local Helios with a unique set of modeling dependencies but those dependencies are very stable.
That was actually my original approach to Buckminster. I wanted to just have a bare minimum target platform and do everything form p2 out of rmaps. But I couldn't get it working..now that I know what I'm doing I seem to be able to get this up and running.
My basic driving principal is to have as few different kinds of artifacts as possible. That means that if I don't have to mess with .target files I won't. My goal would be to have nothing but rmaps and a bare minumum cquery -- I don't even want mspecs if I can avoid it, and while I like ant on its own, I don't like it mixed up in the build chain -- but all of the examples I'm seeing are far from that approach.
| Quote: | The advantage of this approach is that you make the boundaries of each build very distinct. The API becomes the SCM and
p2. No need to bother with the fact that TP's are used at all. And the p2 repository is generally the desired output
anyway so there's no overhead either.
|
Righto! The other major thing is that while you can arbitrarily combine p2s in rmaps, you only get one TP.
| Quote: | The difficulty with this is that it's hard to extend the TP for each individual build. You very quickly run into a
situation where the TP must be copied first (in full) and then extended. As soon as you get to that point it would be
better to create the TP from scratch form a local repository.
|
OK, again that makes sense and turns out to be what my ide builds were evolving toward. Basically:
TP0_Bare + SCM1 = B1 -> P1
TP_Custom + P1 + SCM2 + Px = B2 -> P2
TP_Eclipse_IDE + P2 + Py -> B3 -> SDK
|
|
|
Goto Forum:
Current Time: Sat Apr 27 02:56:52 GMT 2024
Powered by FUDForum. Page generated in 0.03751 seconds |
] 
Search
Help
Register
Login
Home
