FB6 Project Structure and Best Practices

FinalBuilder Discussion
1

I'm doing a 30 day eval of FB6 Pro (with server).. and want to know if there are any well estabilshed "best practices" when it comes to organizing the "Physical Structure" of the final builder projects on disk in my CVS revision control system in relation to my many root level CVS modules that need to compiled to build my EXE and DLL's that make up the final targets.

Unfortunaltly we use a very flat legacy style CVS module structure in my organization...meaning we have lots of CVS root level modules for Visual Studio EXE and DLL projects and solutions with cross dependancies

Should create many isolated Builder Projects for each EXE and DLL and put them the existing CVS modules with the source code

or

Should I create a new root folder in CVS called "BuildSystem" or "FinalBuilds" and build up a collection of FB6 projects that reference all the other root CVS modules?

How does one decide which way to go on this sort of stuff?

Suffering from paralysis-by-analysis!

Heston

 

2

Hi Heston,

I'm sure whether there are any 'best practices' when it comes to structuring your build projects but here's how we currently structure our projects. We have a bootstrap project which performs the 'GET' on two of our source repositories (project and 3rd party components) and then we use an 'Include Project' action to first call a 3rd party component build project which handles building just the external projects, then we call our main project's build script which handles the rest of the build (versioning, labelling, compiling, uploading, etc...).

Having the components built separately allows us to build the common libraries in many projects without having to repeat ourselves.

I'm not really sure whether this will help you get past the paralysis-by-analysis problem, it might just open up a whole new can of worms. All I can suggest is just get stuck in and let is evolve over time.

Regards,
Paul.