More docs on understanding the source tree / source management

Hi,

Just a quick request/plea really.

Would it be possible for anyone with good working knowledge of the source tree to write up tutorials on build practices when working with the source tree?

I fetched the Pi ROM source code last month. DiscDev is another branch with a lot of similarity but different contents – and making an edit to the ROM may well affect the library code shared between the two. So do they always live together, or once downloaded are they kept separately? I merged the two together but there might be better advice than this.

Having done that – what’s the best way of keeping the source up to date so you can build an up-to-date ROM? Do you build your component and test with older stuff, and then when you’re ready to test re-fetch all the source code? We don’t have a full CVS log ‘by default’ so presumably CVS updates will fail.

What’s the best way to build an individual component? So far I hand-run the !Mk files – but is there a better way to use the tools?

sorry if all these seem ‘fundamentals’ – just seems a bit silly I’m sat here coding away and perhaps am not making best use of the build environment.

Rick Murray’s tutorial on setting up the build tree for first use was very useful; really it’s the followup steps after that that would be useful for comparison.

Would it be possible for anyone with good working knowledge of the source tree to write up tutorials on build practices when working with the source tree?

Have you tried looking at the first set of pages linked to from the Technical notes/Building and porting page?

I fetched the Pi ROM source code last month. DiscDev is another branch with a lot of similarity but different contents – and making an edit to the ROM may well affect the library code shared between the two. So do they always live together, or once downloaded are they kept separately? I merged the two together but there might be better advice than this.

Keeping them separate is advisable. Occasionally two different source trees might need to use the same component, but from different branches. This means the sources for that component would be at the same location in the source tree, but the content of the files would be different. E.g. for the first few months of the OMAP3 port the ROM was using the ‘Cortex’ branch of the kernel instead of the ‘HAL’ branch. And with the Raspberry Pi port, that started off using an ‘RPi’ branch of the kernel.

I’m also not sure if the build system copes correctly with the fact that different products use different compiler options. E.g. the Pi ROM will compile everything for ARMv6, while DiscDev compiles for ARMv2-ARMv7. If a module gets built using the DiscDev compiler options and then gets linked into a Pi ROM then it’ll probably be OK, but if you were to build a module using the Pi compiler options and then try running it on an Iyonix or RiscPC then it’ll probably fail. By keeping the two source trees separate you can ensure that you won’t run into problems with compiled code intended for one product being used in the other.

Unfortunately, keeping the source trees separate does make it a bit of a pain when you need to test ROM changes on multiple machine types.

Having done that – what’s the best way of keeping the source up to date so you can build an up-to-date ROM? Do you build your component and test with older stuff, and then when you’re ready to test re-fetch all the source code? We don’t have a full CVS log ‘by default’ so presumably CVS updates will fail.

If you’re working just from the source archives then I think redownloading the whole thing is your only option. However you could at least save yourself some hassle by keeping an eye on the recent CVS revisions and only download a new archive when you spot a change that’s likely to affect what you’re working on. You can also use the CVS viewer to check the VersionNum files for the components you’re working on to see if the version in CVS is newer than the version you’re using.

There are a couple of alternatives to using the source archives:

• You can access ROOL’s CVS server directly – this is the way I and all the other main contributors operate. The Beginner’s guide to ROM builds page has information on how to get started with this approach.
• The tarballs page has tarballs of the raw CVS repository, including tarballs for the changes made in the last day/week/month. But these are more fiddly to use than the direct CVS access since you’ll need to be running a CVS server locally. Depending on how many source trees you need and how often they need updating, I think the CVS tarballs can work out as requiring the least amount of bandwidth compared to the other two options.

What’s the best way to build an individual component? So far I hand-run the !Mk files – but is there a better way to use the tools?

Using the !Mk files is generally the best way of building individual components. If you wanted you could just invoke amu directly from a task window, but the !Mk files sometimes specify extra options (usually just enabling throwback for error reporting, but sometimes extra build options are specified)

Thanks Jeffrey. Yes – I have followed the instructions supplied, and have built my own ROMs. Obviously we’re in a nether-world of version management however by downloading the source, compiling it, patching in changes, and then over time the main source diverges. I suspect from the above the answer is to replace the copy of the sources whenever significant changes have occurred and roll a version for testing purposes. I was thinking about the multiple machine builds too – I have a Pi and a Panda and code will need testing on two platforms. So that would leave the Pi build, the Panda build and the Disc build wanting three source trees.

Sounds like I’m generally doing what you’re doing from the above anyway.