[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: fresh checkout and compile



Hi Guys,

    The simplest way to handle this (one can debate if it's the best) is 
to simply add the proper sequencing to the existing mechanism in the top 
level Makefile. Namely, add the libraries/include and 
programs/Utilities/hddm to the DIRS variable before the libraries 
directory is added.

    It turns out there were a couple of other hiccups though that needed 
to be fixed for this specific case:

1. The hddm-c program was installed into $(OSNAME) rather than $(BMS_OSNAME)
2. The Makefile in libraries/HDDM assumed hddm-c was already in your 
path instead of
   explicitly pointing to the one from the current build (a potential 
problem too if hddm-c
   ever changed and you have hddm-c from another build in your path).

I've gone ahead and made all of these changes and checked them in. It 
seems to build a fresh checkout fine for me now so hopefully it will 
work for everyone else giving Mark a little breathing room to implement 
a more ambitious, longer term solution as he sees fit.

Regards,
-David

Ryan Mitchell wrote:
> Hi Mark,
>
> Thanks for looking at this.  I see the chicken and egg problem.  Of 
> course having all this done automatically (or having the HDDM and HDDS 
> packages separated out) would be ideal, but having the user take a few 
> extra steps isn't absolutely terrible either, as long as its 
> documented, imo.
>
> Thanks,
> Ryan
>
>
> On May 29, 2009, at 9:11 PM, Mark M. Ito wrote:
>
>> Ryan,
>>
>> You are quite right; one should not have to struggle as you did.
>>
>> This "feature" was introduced by me, I am sorry to say.  I made the 
>> switch to having event.xml be the authoritative file. Unfortunately, 
>> this introduces a two-level chicken and egg problem. Level 1: you 
>> need to build hddm-c on the programs side before you do a make on the 
>> libraries side in HDDM. And level 2: you need to do a make in the 
>> include directory on the libraries side in the include directory 
>> before you do the aforementioned make on the programs side. Suffice 
>> it to say the current make system was not designed to deal with an 
>> authoritative event.xml.
>>
>> By the way, your solution is quite reasonable. Doing all this 
>> automatically is on my list. You just moved it to the top. Probably 
>> should have been there before.
>>
>> I should say that I think both HDDM and HDDS should perhaps (in the 
>> future) be broken out of our standard tree and stand independently. 
>> They are really tools, and have no particular knowledge of GlueX or 
>> Hall D or any other particular geometry or data format. That way 
>> these tools could be built first (like we build ROOT and CERNLIB) and 
>> the GlueX-specific build items could go ahead and use them. So, for 
>> example, the hddm-c binary would exist before the GlueX build starts.
>>
>> -- Mark
>>
>>
>>
>>
>> Ryan Mitchell wrote:
>>> Hi All,
>>>
>>> I've been running into some problems when I do a fresh checkout and 
>>> compile of the Hall-D software.  Following the instructions online I 
>>> do...
>>>
>>> >  cd $HALLD_HOME
>>> >  svn co https://halldsvn.jlab.org/repos/trunk/src
>>> >  svn co https://halldsvn.jlab.org/repos/trunk/calib
>>> >  cd $HALLD_HOME/src
>>> >  make
>>>
>>> The compilation makes it all the way to the librararies/HDDM 
>>> directory before it complains about not being able to find the 
>>> hddm-c application.
>>>
>>> I can get things to work eventually.  For example:
>>>
>>> >  cd $HALLD_HOME/include
>>> >  ln -s $HALLD_HOME/src/libraries/include/*.h .
>>> >  cd $HALLD_HOME/src/programs/Utilities/
>>> >  make
>>> >  setenv PATH $HALLD_HOME/src/programs/Utilities/hddm/\:$PATH
>>> >  cd $HALLD_HOME/src
>>> >  make
>>>
>>> but it would be nice (and less frustrating) if the user (me, for 
>>> example) didn't have to struggle this much.  Is there an expert who 
>>> could take a look? Did I do something wrong?
>>>
>>> Thanks,
>>> Ryan
>>>
>>>
>>>
>

-- 

------------------------------------------------------------------------
 David Lawrence Ph.D.
 Staff Scientist                 Office: (757)269-5567   [[[  [   [ [       
 Jefferson Lab                   Pager:  (757)584-5567   [  [ [ [ [ [   
 http://www.jlab.org/~davidl     davidl@jlab.org         [[[  [[ [[ [[[
------------------------------------------------------------------------