Re: automake question

From: Christian Holm Christensen (cholm@hehi03.nbi.dk)
Date: Wed Dec 11 2002 - 20:28:09 EST

  • Next message: Christian Holm Christensen: "Re: Proposing BRAT/bratmain addition (PLEASE READ!)"
    Hi Hiro,
    
    Hironori Ito <hito@rcf.rhic.bnl.gov> wrote concerning
      automake question [Wed, 11 Dec 2002 15:30:15 -0500] 
    ----------------------------------------------------------------------
    > Hello.  I have a question about automake. As I said before, I wanted to 
    > update breg/base to accomodate the new hijing format. (This is already 
    > done in my code.)  But, I have a slight problem to set up right thing in 
    > Makefile.am in breg/base/src (or else). Here is the question.
    > 
    > 1. In breg/base/src, there is "rdzevt.F".  This is the main program, 
    >    which calles user specific program.
    > 2. Currently, in breg/base/src/Makefile.am, "rdzevt.F" is only in the 
    >    pkgdata_DATA entry.  Therefore, it is not compiled. (just moved
    >    to share  directory)
    > 3. I need breg/base to compile rdzevt.F  to an object file so that I 
    >    can link it later with a specific user program. This can be done
    >    by adding "rdzevt.F" to libBregBase_la_SOURCES entry, which
    >    create "rdzevt.o".  But, this is not (???) included in
    >    libBregBase.so. 
    
    The reason why rdzevt.F isn't compiled into libBregBase.so is that it
    is, as you said, a program, and hence it should not be in the
    library.  
    
    The reason why it is installed as source code into 
    
      <prefix>/share/breg/rdzevt.F 
    
    is so that you can later compile it, and link it into your client
    application, along with `-lBregBase'.  Actually, `<prefix>/share/breg'
    is a bad place.  I've changed the Makefile.am so that it is installed
    in `<prefix>/include/breg' so that you can simple do 
    
      c
      c Client code that reads events from a ZEBRA file 
      c
      c Get the program code 
      #include <rdzevt.F>
      
      c
      c Client subroutines 
      c
      c     aninit  : Analysis init
      c     anuser  : Analyze one event
      c     anfin   : Terminate analysis i.e. output results  
      c    
            SUBROUTINE aninit 
    	...
    	END
      c
            SUBROUTINE anuser 
    	...  
    	END
      c
            SUBROUTINE anfin
    	...  
    	END
      c
    
    The point is, that we don't want to compile `rdzevt.o' until we link
    in the user code.  
    
    The changes have been commited (along with a few other changes to the
    build stuff). 
     
    > The main question is what is the right way to do this. But, I also
    > have a few other questions.
    > a.) Is there a way to know what is in ????.so file. 
    
    Yes (on GNU/Linux at least), use `nm' (see the info pages for more
    docs).  
    
    > b.) Is there a way to use(link with) a specific program from
    >     ?????.so file. 
    
    That's a funny question, considering that ROOT, BRAT, BREG, BROP,
    BRAG, and ladida does exactly that.   Anyway - it's really simple.
    Suppose you have `libFoo.so' in `/path/to/library', then you do one of  
    
       c++ -L/path/to/library -lFoo my_app.cc -o my_app  
       f77 -L/path/to/library -lFoo my_app.F -o my_app 
       cc  -L/path/to/library -lFoo my_app.c -o my_app 
    
    Also, look at the various source tree's in BRAHMS and see how it's
    done there. 
    
    > c.) How can I move ???.o to ~/lib directory if I want to.
    
    Don't (if you're thinking about `rdzevt.F').  Just include it as shown
    above.  Much simpler for the client code to deal with.  
    
    Yours, 
    
     ___  |  Christian Holm Christensen 
      |_| |	 -------------------------------------------------------------
        | |	 Address: Sankt Hansgade 23, 1. th.  Phone:  (+45) 35 35 96 91
         _|	          DK-2200 Copenhagen N       Cell:   (+45) 24 61 85 91
        _|	          Denmark                    Office: (+45) 353  25 305
     ____|	 Email:   cholm@nbi.dk               Web:    www.nbi.dk/~cholm
     | |
    


    This archive was generated by hypermail 2.1.5 : Wed Dec 11 2002 - 20:51:10 EST