[Halld-offline] Confusion about JANA build

[Matthew Shepherd]

Hi Dave,

On Mar 12, 2011, at 10:22 PM, David Lawrence wrote:

>> I recently did svn update on my copy of jana.
> Let me stop you right there. You should never, ever, ever, under any circumstances (other developing JANA code itself), update from the JANA repository. If you are compiling JANA to use for Hall-D software, then you should always be using a tagged release built from a tarball distributed from the JANA website.

My fault...  I'm using the automated build scripts that were distributed.  Upon further examination if one does not set some environment variables these scripts automatically do a fresh checkout from the repository.  So me along with most others I know who are using the build scripts probably aren't using a fixed release of JANA.  I understand the idea behind Mark's logic -- it guarantees the scripts will work.  It underscores the need for documentation  on how the scripts should be used.  (I know... I should know better than to use the repository for jana!)

>> When one is building the JANA library itself, one is relying on the fact that all headers are accessible from . or .. (which is the case) to avoid pulling in old headers installed in src/../include.  However, when the build moves on to the utilities the paths . and .. and no longer are sufficient to get headers (One needs ../.. also.) and old stuff comes in through src/../include.
>> 
> So, I guess there is something I'm missing here since the structure I describe above and observed just now when building JANA 0.6.3 is that you can't really have old stuff in src/../include by the time you get to src/utilities. Could you give a few more details on exactly the commands I would need to do to reproduce the behavior you're seeing?

With my current version of JANA (whatever is in the repository) I can do the following:

go to src/../include  (the include directory "level" with src)  -- I assume this is the install directory

remove a file, say JCalibration.h

go to src

"make" will fail but "make install" will work

>> It would be nice to see something similar for the main halld tree.  This would guarantee that each build was using fresh headers and libraries, not previously installed.
>> 
> I've been wanting to move the Hall-D source over to using autoconf and perhaps simultaneously tighten up the build system. The Hall-D source is a little different in nature from JANA though. With JANA, we can treat it as a purely 3rd party package like Xerces or ROOT. The Hall-D source is going to be more of a user malleable entity so may need a more flexible build system. We should add this to the agenda of the next offline meeting.

To give another concrete example of how this causes trouble with the Hall D system:  if one removes a class or header file and then commits the change to the repository, subsequent builds of the tree can still utilize the header that was previously installed in the install path.  Although I can't verify it, I'm pretty sure this is what happened with Simon when he removed DParticle.h a couple days ago.  I did a fresh checkout and build (including manually wiping out my old install areas) and the build failed because a few pieces of code (unnecessarily) included DParticle.h.  If Simon didn't manually delete these headers from the install area after removing them from the source tree, he would not have been able to detect this problem.

I agree with what you say that the style of the Hall D system is different from other packages.  I would almost advocate for an "install" of only binaries into common directory to make execution easier.  The odds that the typical Hall D user will use headers and libraries in the fashion of a third party package are slim.  An alternative may be to have an uninstall target that allows the make system to clean the install area before installing a fresh stuff.

-Matt