 |
 |
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] > > > -- Org: CERN, European Laboratory for Particle Physics. Mail: 1211 Geneve 23, Switzerland E-Mail: [log in to unmask] Phone: +41 22 7679248 WWW: http://fons.rademakers.org Fax: +41 22 7669640