Fabrizio,
if you want the stuff in ${prefix}/etc/ you just change the line in
src/Makefile.am:
xrootdstartupdir = $(sysconfdir)/xrootd
->
xrootdstartupdir = $(sysconfdir)/
That's a very trivial operation and has exactly the result you want.
Cheers Andreas.
> 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]
>
>
>
>
--
