 |
 |
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. 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] > > >