Hi Andreas,
thank you for the suggestion. I will try it out immediately.
I believe what we all need is a standard, easy way to deploy it and
make it start. I am not against autotools, and I am perfectly aware
that the idea of using them could lead to good things. And I am aware
that the classic build is good for a developer, but lacks a decent
install. This is why the standard install was meant to be through an
rpm, which also sets up the /etc/init/d stuff.
The point is that, right now, to make a server start, you need to do
unspecified (at least, to me) things if you just type make install.
After having run it I did not see anything useful in /etc/init.d/,
did I do anything wrong or do I have to write my own init.d scripts?
Fabrizio
Il giorno 13-dic-07, alle ore 16:56, Andreas Joachim Peters ha scritto:
> 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]
>>
>>
>>
>>
>
> --
Fabrizio Furano
[log in to unmask]
