Re: [SWIPL] Suggestion for the DarwinPorts version of SWI-Prolog
Roberto Bagnara bagnara@cs.unipr.it wrote: I may well be missing something, but it seems the life of people interfacing C/C++ and Prolog programs on MacOS would be simplified if SWI-Prolog.h and the other interface header file could be installed in some fixed place, such as /opt/local/include, as well as in /opt/local/lib/swipl-x.y.zz/include.
Yes, you are missing something, and no, my life would not be simplified. If a package installs things in a fixed place, then I cannot install it. Nohow.
Let me explain why. This university has a policy that if a machine is connected to the University net, then it MUST be administered ONLY by an approved system administrator who is basically responsible for keeping antivirus stuff up to date, installing the approved e-mail software, and basically ensuring that bad stuff doesn't happen. ONLY the approved system administrator is allowed to know the root password.
It doesn't matter who *owns* the machine. I have an old Sun-3/50 and a 486 PC in my office which *could* be connected to the net, and I'm about to get a past-its-wow-gosh-date Windows NT box ditto. But if I want them connected to the University net, I will NOT be allowed to know what the root password is, even though they're my machines. The G4 Mac running MacOS X and the SunBlade100 running Solaris 2.9 that sit side-by-side on my desk, on which I do my real work, belong to the University, and there is no way that they are ever going to let me have the root password on those machines as long as they are connected to the University net.
This means that I *cannot* install software that puts things in /usr or /opt or *anywhere* except my own directory or /tmp. If I want such software to be installed, I have to ask the appropriate system administrator nicely (different sysadmins for the Solaris box and the MacOS X box, by the way), and wait for them to fetch the software, check it out for unrighteousness, and install it, in their own good time. (These are busy people.) I had to wait months for one such package.
P.S. BTW, why /opt/local instead of /usr/local?
From my Solaris box:
% man -s 5 filesystem /opt Root of a subtree for add-on application packages.
The file system mounted on /usr contains platform-dependent and platform-independent sharable files.
On the MacOS X box it's "man 7 hier" instead of "man -s 5 filesystem" and there isn't any /opt.
Richard A. O'Keefe wrote:
Roberto Bagnara bagnara@cs.unipr.it wrote: I may well be missing something, but it seems the life of people interfacing C/C++ and Prolog programs on MacOS would be simplified if SWI-Prolog.h and the other interface header file could be installed in some fixed place, such as /opt/local/include, as well as in /opt/local/lib/swipl-x.y.zz/include.
Yes, you are missing something, and no, my life would not be simplified. If a package installs things in a fixed place, then I cannot install it. Nohow.
Let me explain why. This university has a policy that if a machine is connected to the University net, then it MUST be administered ONLY by an approved system administrator who is basically responsible for keeping antivirus stuff up to date, installing the approved e-mail software, and basically ensuring that bad stuff doesn't happen. ONLY the approved system administrator is allowed to know the root password.
It doesn't matter who *owns* the machine. I have an old Sun-3/50 and a 486 PC in my office which *could* be connected to the net, and I'm about to get a past-its-wow-gosh-date Windows NT box ditto. But if I want them connected to the University net, I will NOT be allowed to know what the root password is, even though they're my machines. The G4 Mac running MacOS X and the SunBlade100 running Solaris 2.9 that sit side-by-side on my desk, on which I do my real work, belong to the University, and there is no way that they are ever going to let me have the root password on those machines as long as they are connected to the University net.
This means that I *cannot* install software that puts things in /usr or /opt or *anywhere* except my own directory or /tmp. If I want such software to be installed, I have to ask the appropriate system administrator nicely (different sysadmins for the Solaris box and the MacOS X box, by the way), and wait for them to fetch the software, check it out for unrighteousness, and install it, in their own good time. (These are busy people.) I had to wait months for one such package.
Hello Richard,
you are also missing a few things.
The first one is that I did not ask Paulo to modify his package so that it "installs things in a fixed place". Either it does it already (i.e., it always installs under /opt/local/) in which case I am fine, or it does not (i.e., it allows replacing /opt/local/ by /tmp/richard/ or any other prefix of choice), in which case I am fine anyway.
The second thing is that if you cannot install under /opt (or /opt/local/) this means that for you /opt/local/include is out of reach exactly as /opt/local/lib/swipl-x.y.zz/include so that your life would not be simplified, but would not be made harder either.
The third thing is that my proposal is simply to improve portability by matching what Jan's makefile already does on all Unix/GNU platforms:
cd ../include; \ for f in SWI-Prolog.h SWI-Exports SWI-Stream.h stub.c; do \ if [ -f $$f ]; then \ $(INSTALL_DATA) $$f $(PLBASE)/include; \ fi; \ done if [ -d $(prefix)/include -a -w $(prefix)/include ]; then \ $(INSTALL_DATA) ../include/SWI-Prolog.h $(prefix)/include; \ $(INSTALL_DATA) ../include/SWI-Stream.h $(prefix)/include; \ fi
where PLBASE=$(prefix)/lib/@PL@-$(PLVERSION). So, if $(prefix)/include is a directory and it is writable, then the headers are also installed there.
Said all that, I am now changing the PPL configuration script so as to call `pl -dump-runtime-variables' and then parse back the definition of PLBASE to know where the C include files are located. This, I believe, will increase portability even more. Cheers,
Roberto
Off-topic P.S. I really wonder how can people in CS departments accept impositions such as the one of not being allowed to know the root password of their own machines. Not to criticize anyone: I know this happens in several CS departments, but still I find it completely unacceptable. I am willing to (and did) sign papers where I take full responsibility for any damage or violations that can be caused by my systems, but I am not willing to be declared, a priori, totally uncapable of granting any reasonable level of system security.
participants (2)
-
Richard A. O'Keefe -
Roberto Bagnara