On a newish x86_64 machine without no-pie running Ubuntu 20.04,
everything goes smoothly.
The main difference that your setup makes to me as end user is having to
type "poplog pop11" (or ved, or xved or whatever) instead of just
"pop11". Of course I can set up aliases or links for myself, but I
imagine that you have reasons for doing it this way. As far as I can
see, using the poplog script means setting up a fresh poplog environment
for every pop11 call, rather than the old way of setting up the
environment once at each login. On a modern machine, I suppose the time
taken in defining the poplog variables is negligible and maybe there is
something to be gained by not cluttering up the environment between
poplog calls.
Anyway, thanks very much for keeping poplog alive.
Stephen Isard
On Wed, 7 Jul 2021, hebisch-at-math.uni.wroc.pl |pop-forum| wrote:
I have now commited new build system to github repo. Beside content
of repo you also need working corepop (not contained in the repo).
Short step by step instruction for 64-bit PC Linux:
0. Go to directory where you will build poplog
1. Fetch sources:
git clone --depth=1 https://github.com/hebisch/poplog .
2. Make directory for corepop:
mkdir -p target/pop
3. Fetch corepop:
wget https://www.math.uni.wroc.pl/~hebisch/poplog/corepop.amd64
4. Turn on executable bits on fetched corepop:
chmod 755 corepop.amd64
5. Move corepop to proper place:
mv corepop.amd64 target/pop/corepop
6. Run configure:
./configure
7. Make new corepop:
make stamp_new_corepop
8. Replace old corepop by new:
mv target/pop/new_corepop target/pop/corepop
9. Build:
make
After that at top of build directory there will be a script called
poplog and you can do:
./poplog pop11
etc, to run poplog commands. If desired you can move poplog script
to other place (like /usr/local/bin). poplog script contains paths
to build directory, so it will find parts of poplog even when
invoked from other place. You can also move pop and target subtrees
to other places, but this requires editing paths embedded in poplog
script. In the future we will probably add install target to the
makefile which will put Poplog files to final place and produce
appropriate commands.
Remark: Of course commands above could be gathered into a
"download and build" script. I am not doing this now because
you may wish to change step above.
Some deeper explanations:
- configure script detects architecture, so given working corepop
this should build also on arm (32-bit) and i386
- configure script detects if we need -no-pie option to C
compiler, this causes compilcation to the build process
- corepop.amd64 is intended to be usable on many different
machines. It was build on moderately old machine (on
which -no-pie fails) with option which in principle
allows it to run on very old machines. OTOH it contains
workaround for 5.8 kernel and does not link to ncurses,
so it avoids all known to me problems on new machines
- configure script detects if we can link to Xt or Motif,
if there is not Xt on machine, then it will configure link
without X support, if there is Xt, but not Motif it will
link configure with Xt, if there is Motif it will configure
link with Motif
- Makefile and poplog script are created by configure using
templates (Makefile.in and scripts/poplog.in respectively) and
replacing some strings
- I have separated sources from binaries: all binaries are
created in target subdirectory. If you depend on traditional
layout of Poplog you may move parts of installation back
to old placed and adjust paths in the poplog script. Or
you can adjust to new layout
I would in particular appreciate info if corepop.amd64 works
on your machine. Also, I am interested of your opinion about
new directory layout. Currently I use "target" as name of
directory for binaries, which is a bit silly. We probably
should use someting like target/x86_64 or x86_64, that
is encoding architecture name (with architecture specific
name we can have multiple architectures in the same tree).
This makefile is experimental, it works for me on few
machines, but I would appreciate info if it works on
your machine. Let me add that this build system assumes
resonably standard system. It will surely fail on
ancient Unix variants with buggy basic utilities.
OTOH it has resonable chance of working on say FreeBSD
(possibly after some minor tweaks).
One more comment: I skipped old scripts from 'pop/com'
subdirectory like 'mkeliza' or 'popenv.sh'. Some
of them may work with this system, some probably require
changes. However, normal use should be possible just
via 'poplog' sript. I would appreciate comments on
what features of old system that changed in this one
you consider important.
Let me add that I consider changes to dirctory layout
and ommision of old scripts as a proposal and voice
in discussion. Old layout and script could be easily
restored, but the question is if benefits of old way
are greater then disadvantages.
--
Waldek Hebisch
