Ok Andreas, thanks.
So we can commit something general which can help in setting up a  
simple system in a simple way. I realized that this is a problem which  
is worse than I thought. Better late than never, but maybe I should  
have realized this before. At least 4 naive script sets to do the same  
thing seems a bit too much to me just to continue believing that  
everything is fine...

Fabrizio


Il giorno 14-dic-07, alle ore 00:18, Andreas Joachim Peters ha scritto:

> Fabrizio,
> I pass by tomorrow and we can produce what you need in half an hour.  
> You will see, you can live perfectly with the autotools make as it  
> is - we need just one tiny
>
> modification and we can produce two init.d scripts with copy and  
> paste from the CAF or Castor ones.
> We should also fix LD_LIBRARY_PATH in StartXRD etc. for Mac  
> (DY_LD_LIBRARY_PATH) and should cover the library location on 64bit  
> machines (lib64).
>
> Cheers Andreas.
>
> -----Original Message-----
> From: Fabrizio Furano [mailto:[log in to unmask]]
> Sent: Thu 12/13/2007 7:34 PM
> To: Fons Rademakers
> Cc: Derek Feichtinger; [log in to unmask]; Wilko Kroger; [log in to unmask] 
> ; Andreas Joachim Peters
> Subject: Re: Autotools install
>
> Hi Fons,
>
>   I agree with you. I don't want to throw away the autotools build,  
> but I
> don't want to throw away the classic build, since it's the one that  
> up to
> now works without having to mess up too much, and it's more easily  
> adaptable.
>
>   In general, what should be achieved is that after the 'make' the  
> software
> works locally, and a 'make install' installs it system-wide, like in  
> the
> ROOT case btw.
>
>   My point as a developer is that the autotools build fails the  
> validation
> now, so the bridges we should burn are the ones which are built on  
> top of
> the current status of it. Just too obscure and complicated to start  
> even a
> simple system. An indication of this should be that afaik the only  
> customer
> of it is Alice, due to the decision of choosing the placement of the
> various pieces with a very fine granularity, and the classic build  
> cannot
> do that, because it lacks a 'make install', but for the rest is  
> perfect.
>
>   Only doing that IMO we can fix the autotools or classic build  
> without
> making it more complicated, no matter if in Alien or xrdcastor or  
> Proof
> there can be a lot of naive scripts to fix (or purge/simplify)  
> accordingly.
>
>   From my perspective there are not so many things to fix, and an  
> init.d
> startup script to add. My wishlist is as follows:
>
> - right after make:
>    - the libs should be in a unique visible directory lib
>    - the executables should be in a unique visible directory bin
>    - etc, utils and similar should stay where they are now
>   ... otherwise the developers will never consider seriously to  
> adopt it.
>
> - after make install:
>    - a possibly unique init.d script is there
>    - if I start it, both xrootd and cmsd start in a very basic  
> fashion,
> serving data from /tmp and trying to subscribe to a fake manager
>    - the init.d script invokes the classic StartXRD/OLB scripts
>    - the utils package should appear somewhere as it is in the pre- 
> install
> tree, i.e. without spreading its content. A nice place could be in
> ...etc/xrootd/utils
>
>   I'd like to hear the opinion from the guys who are involved,  
> however.
> Again, my point now is that I am puzzled about what should I do to  
> set up a
> cluster. Writing my own (new?) scripts over the current autotools, the
> classic make, or devoting this time to enhance the current make system
> instead of thinking about the Nth workaround?
>
> Fabrizio
>
>
>
>
> Fons Rademakers wrote:
> > THe main problem is that the old system has been kept alive. You  
> need to
> > burn bridges to go forward. In ROOT we use several other OS packages
> > based on autotools (freetype, pcre, libAfterImage). No problems to  
> use
> > the from our build system. It is up to the xrootd developers to  
> validate
> > the new auotools system and throw out the old one. We will be  
> happy to
> > adapt to it.
> >
> > Cheers Fons.
> >
> >
> > Derek Feichtinger wrote:
> >> Ciao, Fabrizio
> >>
> >> On Thursday 13 December 2007, Fabrizio Furano wrote:
> >>> Hi Derek,
> >>>
> >>>   I appreciate your responsiveness, but I don't want to steer into
> >>> philosophical talks. Maybe ZX spectrum was better than C=64, but  
> I don't
> >>> care now.
> >>
> >> Well, I did not want to sound philosophical, but I tried to state  
> the
> >> real advantages and disadvantages as I see them. Xrootd has made an
> >> own standard of its build and deployment structure, and a large  
> number
> >> of users have adapted to this. The autotools build follows a very
> >> widely spread standard in unix software engineering, and this was  
> also
> >> why I was asked to implement it (which caused me and Gerri a lot of
> >> work at that time). I still think that it is worth make a  
> reasonable
> >> effort to try to comply with standards, but naturally in the crazy
> >> fast changing world of software development, reasonable is defined
> >> very differently by the users.
> >>
> >> As I said. I can introduce and adapt the configure easily, if  
> this is
> >> needed and if you can suggest to me exactly what you want. On the
> >> other hand, one could rethink the decision to support autotools.
> >> However, if xrootd gets a wider range of users, as it certainly
> >> deserves, it may be an advantage to keep the autobuild, especially
> >> since the main work has already been done.
> >>
> >> Cheers,
> >> Derek
> >>
> >>
> >>
> >>>   The point is that there are tenths of sites (with many different
> >>> architectures, and not only babarians) using the plain classic  
> build and
> >>> the rpms that Wilko provides.
> >>>   So, from my perspective, I just see that if I try to use the  
> autotools
> >>> build:
> >>>
> >>> - as a developer i don't feel comfortable with it. For instance,  
> I don't
> >>> want to choose if to look at the libraries in a hidden directory  
> or
> >>> being
> >>> forced to install everything in /usr/, or having to look at the
> >>> executables
> >>> in N different places.
> >>> - if I want to setup a cluster, or even a single server, I have no
> >>> clue at
> >>> all about how to start it, since the bundled scripts (used by a  
> lot of
> >>> people) do not work.
> >>> - I don't want to mess up things and write shell scripts on top of
> >>> something just to start my own executables (btw this is what Alien
> >>> seems to
> >>> do, workarounds over workarounds). It should just work out of the
> >>> box, like
> >>> in the classic case.
> >>>
> >>>
> >>>   Given this, which I think is pretty pragmatic, I'd like to be  
> even
> >>> more
> >>> pragmatic. Since this morning I am fighting to install a manager  
> with a
> >>> trivial config file, with no success. This makes me quite upset.  
> I am
> >>> not
> >>> able to deal with my own stuff.
> >>>   I switched back to configure.classic and it works. So, I have no
> >>> idea of
> >>> what's good or bad, but please, if you have a clean list of
> >>> hints/fixes to
> >>> do, my wish is to work together and put the 'alternate' build  
> system
> >>> in a
> >>> state where it is usable and it does not need workarounds.
> >>>   For how it is now, if I have to setup a cluster somewhere, I  
> will
> >>> simply
> >>> ignore it, but that's not what I'd prefer.
> >>>
> >>>   I hope that I don't make you upset with this. Let's make this  
> thing
> >>> work
> >>> together if you want.
> >>>
> >>>
> >>> Fabrizio
> >>>
> >>> Derek Feichtinger wrote:
> >>>> Hi, Fabrizio
> >>>>
> >>>> I'm sorry that you have so much fuzz with this.
> >>>>
> >>>> Some comments follow:
> >>>>> So, if I keep the default prefix /usr/local, I expect to have  
> the
> >>>>> config files in /usr/local/etc, and the libs in /usr/local/ 
> lib, but
> >>>>> what I see now is that "make install" puts that stuff into / 
> usr/local/
> >>>>> etc/xrootd and similar for lib.
> >>>> The choice for $PREFIX/etc/xrootd instead of just $PREFIX/etc  
> was taken
> >>>> because an administrator does not want /etc cluttered with a  
> whole
> >>>> number
> >>>> of files from a single package, so it is nicer to have it in a  
> separate
> >>>> directory named for the service.
> >>>>
> >>>> StartOLB
> >>>> StartOLB.cf.example
> >>>> StartXRD
> >>>> StartXRD.cf.example
> >>>> StopOLB
> >>>> StopXRD
> >>>> XrdOlbMonPerf
> >>>> xrootd.cf.example
> >>>>
> >>>> I can easily build in an option, if this is a problem (hardcoded
> >>>> locations?). But usually, one wants to have typical init  
> scripts which
> >>>> fit into a system's service startup and shutdown structure.
> >>>>
> >>>> For the libraries you looked wrongly, for they are in $PREFIX/lib
> >>>> and not
> >>>> in a separate folder. This would break the standard convention  
> for
> >>>> libraries. But the include files are also segregated into
> >>>> $PREFIX/include/xrootd/ for better structuring.
> >>>>
> >>>>>   This is not compatible with the standard StartXRD scripts,  
> which
> >>>>> everybody use (except Alice afaik). What do you think about  
> this? Are
> >>>>> you aware of any workaround for that?
> >>>> While I was working for ALICE, we always used custom scripts.  
> But since
> >>>> xrootd needs a minimum of switches and mainly relies on the  
> config
> >>>> files,
> >>>> this never seemed a drawback to me. It involved just a few  
> lines of
> >>>> shell
> >>>> code.
> >>>>
> >>>>> Btw in the meantime, I will
> >>>>> install my machines like I always did, i.e. with the plain
> >>>>> configure.classic, but that is not what the Alice guys are  
> used to,
> >>>>> even if it's much simpler by now imho.
> >>>> Well, configure.classic works well and is faster than the  
> autotools
> >>>> build. But autotools is still _the_  standard in the build  
> system and
> >>>> portability world. New systems like cmake are popping up, but  
> these
> >>>> things are really difficult and painful to develop, and they  
> take long
> >>>> until a big community adopts them.
> >>>>
> >>>> Also, if you look at a xrootd Makefile.am and then at the  
> corresponding
> >>>> classic GNUMakefile, the Makefile.am is structured much simpler.
> >>>> It is trivial to build RPMs and other packages from an  
> autotools build,
> >>>> since it correctly observes the DESTDIR setting (packaging  
> directory),
> >>>> and the libraries correctly contain the right -rpath, so that no
> >>>> LD_LIBRARY_PATH needs to be set.
> >>>> Autotools configure is slower, because it makes real  
> compilation tests
> >>>> for the system's features. The generated configure script shows  
> all the
> >>>> standard behavior expected by users and offers a wide range of  
> user
> >>>> options. Also, you can build multiple architectures from the same
> >>>> sources, e.g. by having them on a shared filesystem.
> >>>>
> >>>> Configure.classic is a separate and well working system, but it  
> has
> >>>> completely non-standard behavior and if I want to deploy  
> software in a
> >>>> standard way, I have to do extra work.
> >>>>
> >>>> The technology used by autotools to generate the configure (m4,
> >>>> etc.) is
> >>>> too old and inconvenient, and some things are clearly too  
> complex.
> >>>> However, since so much work has been done before, you usually  
> don't
> >>>> have
> >>>> to deal with these kind of issues, and you more or less just  
> use the
> >>>> ready made macros. Don't forget that a large part of the  
> complexity
> >>>> comes
> >>>> for the innate problems that portability implies - years of  
> operations
> >>>> systems development and complex and subtle differences across  
> their
> >>>> versions.
> >>>>
> >>>> Sorry again for your losing time because of these issues, but  
> it really
> >>>> was hard for me in the last few weeks to pay close attention to
> >>>> this, and
> >>>> keeping a separate build is not always easy.
> >>>>
> >>>> Cheers,
> >>>> Derek
> >>>>
> >>>> On Thursday 13 December 2007, Fabrizio Furano wrote:
> >>>>> Hi Derek,
> >>>>>
> >>>>>   well, I am sorry to bother you so much, but I am not able to  
> get out
> >>>>> from this maze.
> >>>>>
> >>>>>   The problem I find is that when I make install, it puts the  
> things
> >>>>> in a way which looks incompatible with the normal start/stop  
> scripts,
> >>>>> which hence do not work. This may be one reason for the bloody  
> mess of
> >>>>> alternative install/start/stop scripts that I see around.
> >>>>>
> >>>>> So, if I keep the default prefix /usr/local, I expect to have  
> the
> >>>>> config files in /usr/local/etc, and the libs in /usr/local/ 
> lib, but
> >>>>> what I see now is that "make install" puts that stuff into / 
> usr/local/
> >>>>> etc/xrootd and similar for lib.
> >>>>>
> >>>>>   This is not compatible with the standard StartXRD scripts,  
> which
> >>>>> everybody use (except Alice afaik). What do you think about  
> this? Are
> >>>>> you aware of any workaround for that? Btw in the meantime, I  
> will
> >>>>> install my machines like I always did, i.e. with the plain
> >>>>> configure.classic, but that is not what the Alice guys are  
> used to,
> >>>>> even if it's much simpler by now imho.
> >>>>>
> >>>>> Fabrizio Furano
> >>>>> [log in to unmask]
> >>
> >>
> >>
> >
>

Fabrizio Furano
[log in to unmask]