#5 Top Level Build Structure

[Sinisa Veseli]

It seems some people (namely Greg and Sinisa) would like to change the model for building the C++ modules
that we've been using up to now. Personally it doesn't bother me, I'm happy with the status quo and making the

change may generate more, for me, unnecessary work, but I'm certainly not against the change if people feel it’s required.

There've been a couple a comments on the idea on the emails, but nothing that looks like a clear decision. I'm not sure

whether the general silence on the issue indicates disagreement with Greg and Sinisa or is apathy/being busy doing other

things/being out the office.

We need to make a decision on whether we are going to make this change and if so how, before we can much further
forward. This affects what goes into the release, the release scripts and the getting started guide and may also require
changes to exampleCPP. Until we make a decision on these it's hard to make progress on anything until we do (especially
for me as I'm involved in all these areas).

So

1. Are we going to recommend using a top-level structure for building the V4 modules (e.g. will the getting starting guide

recommend putting the macros in a single location instead of in each individual module configure/RELEASE.local).

1. If so, are we going to supply any top-level files (e.g. makefile, build script)?

2. If so, what form are these going to take (Makefile, build script etc.)?

3. Who is going to write these?

4. Where are we going to put these top-level makefiles etc.? Are they included in the tarball? If so we might put them in
   pvDataWWW/scripts (in which case I'll modify my script to fetch with wget). However how does someone get them if they
   are building from the mercurial repos? wget? Alternatively we could have a top-level module for this type of stuff.

5. What should any top-level makefile build.? Does it include the 2 examples in exampleCPP? This creates a dependency on
   the EPICS ChannelArchiver. So anyone wanting to build from the top-level will get build errors if they don't have the
   ChannelArchiver installed, irrespective of whether they want to use the V3 ChannelArchiver or the V4 ChannelArchiver Service.
   One option is to have the script build HelloWorld and comment out building ChannelArchiverService by default. Another is to have
   a default target that excludes ChannelArchiverService and another that build all.

6. If the top-level makefile/script builds the examples does it build them separately

e.g.

make -C exampleCPP/ChannelArchiverService

make -C exampleCPP/HelloWorld

or do we add a top-level (within exampleCPP) makefile and do

make -C exampleCPP

(My preference would be the former. That way we can comment out one the Channel Archiver Service at this level if not

required and it requires the fewest changes to exampleCPP.)

Regards,

Dave

[Sinisa Veseli]

The main issue here is addition of top-level makefile that would allow users to build software with a single command, without having to worry about creating RELEASE.local files in every subdirectory, worrying about dependencies, order in which products are built, etc.

Although the build process must be documented in detail, the quick start guide could be reduced to something like "export EPICS_BASE=/path && make". This is similar to what most open source software aims for in terms of builds (simplicity, such as "configure && make make install").