axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damitha Kumarage <damith...@gmail.com>
Subject Re: [AXIS2C] install folder
Date Tue, 31 Jan 2006 03:10:46 GMT
Anuradha Ratnaweera wrote:

>On 1/27/06, Damitha Kumarage <damitha23@gmail.com> wrote:
>  
>
>>deploy is just a sample directory in our source tree to represent
>>the install directory.  When we do make install in source it is
>>installed in the path specified as configure prefix...
>>    
>>
>
>+1 for keeping the prefix approach.  IMHO, the ideal installation
>would look like the following, which will make axis2 not look out of
>the place among other well established C programs.
>
>- User sets the --prefix, which defaults to /usr/local/, but software
>distributions (RPM, DPKG, emerge etc) make it default to /usr. lib/,
>include/ and bin/ should be created inside prefix.
>
>- Libraries (*.so, *.la and *.a files) *should* be installed to lib/
>directory inside prefix.  If prefix is /usr/local/, then this will be
>/usr/local/lib/.
>
>- The best names for the axis 2 library would be libaxis2.la,
>libaxis2.a, libaxis2.so.  If it is defined as lib_LTLIBRARIES =
>libaxis2.la, everything else should be looked after properly.  With
>the default prefix, you will get /usr/local/lib/libaxis2.{a,la,so}. 
>None of the C libraries I have seen have a "_deployment" part... ;-)
>
>- Header files *should* go into include/ directory inside prefix.  But
>since the number of header files are large and as they are specific to
>axis2, general practice is to create a subdirectory (just go through
>/usr/include/ to see how true this is).  So, the best option is to
>install them into include/axis2/.  If the same can be done to the
>source tree (move include/*.h into include/axis2/, test programs will
>find it easy).
>  
>
+1 to have include/axis2

>- Test programs are generally not installed.  A typical installation
>  
>
true, instead we should install our samples. isn't it?

>should look like:
>
>    ./configure
>    make
>    make test  # optional
>
>    make install
>    make clean # optional
>  
>

>Running make can build test programs, but make test can look after
>running them and see if they really work.
>  
>
I guesss make test can run all our unit tests and system tests and 
verify that
everything is ok. If that is so let's do it ASAP which will make the 
life so much
easy :)
thanks
damitha

>        Anuradha
>--
>http://www.linux.lk/~anuradha/
>http://anuradha-ratnaweera.blogspot.com
>  
>


Mime
View raw message