[PPL-devel] Re: Suggestion for the DarwinPorts version of SWI-Prolog

[Roberto Bagnara]

Richard A. O'Keefe wrote:
> Roberto Bagnara <bagnara at 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 at -$(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.

-- 
Prof. Roberto Bagnara
Computer Science Group
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:bagnara at cs.unipr.it