Moving the SYN Tools to Other Platforms

1 April 2009

The SYN tools were originally intended as no more than a "proof of
concept" quick-and-dirty implementation that would show that it is
in principle possible to calculate system properties from component
measurements.  They were implemented on a GNU/Linux system with little
regard for possible use on other platforms.  Perl was chosen as the
implementation language partly because it is available for a variety of
platforms, but liberal use was made of its `system' function to execute
GNU utilities and a Linux shell to do things like

  system("rm -f foo; cp -p baz foo")

to copy a file, or

  system("echo $inputval | ./code")

to execute a program and send it input.  As the tools `just growed'
they were fitted more and more to GNU/Linux and problems of the moment
were solved without a qualm about portability.  It was early decided
to use GNUPlot as the primary output generator, again without considering
portability.

But Perl really does try to be platform independent, and Perl modules can
replace shell commands, in the two examples above the File::Copy module,
and the IPC::Open3 module that executes code and can pass it input and
collect its output.  When standard modules were substituted, the Perl
scripts run even on MS windows systems.  GNUPlot also has aspirations
of platform independence.

Two specific platforms are covered below; the only general difficulties
that might be encountered arise from getting Perl and GNUPlot in place,
and from platform philosophies that make the command-line style difficult
to use.  There is considerable help available in the Perl documentation
for moving to a wide range of platforms, and GNUPlot can be built from
sources almost anywhere.

It would be relatively easy to arrange for part of SYN to work in `point and
click' mode on any system that has such an environment (even Linux!).
Scripts could be run when a user clicks on the configuration files, e.g.,
a component-measurement script for a `.ccf' file, and the main synthesis
script for `system.pscf'.  That would be a stopgap but no substitute
for redesigning the tools to really use a GUI.  To obtain the full
functionality of the command-line tools it's best to stick to commands.
It isn't hard to type a command with no arguments as an alternative to
a mouse click.  Although the X-windows system can usually be installed
easily, the simplest conversions will rely on GNUPlot to take care of
its windows and avoid the complications of installing X11.

A `setup' module is provided to parametrize the SYN scripts for
different platforms.  The script (`setup.pm') has been made easy to
modify for new platforms.  If the SYN tools refuse to run, `setup.pm'
may require modification.  It may be that your platform has a name
different than the ones checked in `setup.pm'; you can discover that
name through the Perl `$O' variable and adjust accordingly.


Apple Macintosh OS X (Intel)

As might be expected, even shell-ridden Linux code runs almost `out
of the box' under the newer Mac OS X based on FreeBSD UNIX.  Perl is
distributed with those systems, and installing GNUPlot is straightforward.
It's a good idea to install the `Xcode' package, which provides the
GNU C compiler.  SYN tools can be used in the `terminal' command-line
window that provides access to FreeBSD directly with a `bash' shell.
Some GNUPlot installations require the `Aqua' package for graphics
support; some require `x11'; some require both.  For users without
UNIX command skills, a mixture of regular Mac operations to manipulate
files and `terminal' to execute SYN tools on those files is indicated.
Depending on how GNUPlot was installed, `setup.pm' may require a different
`set terminal' type than the most usual `aqua'.

Files can be directly edited in a `terminal' window with (say) `vi',
and there is no difficulty with unusual extensions like `.ccf'.

In Mac OS prior to the conversion to FreeBSD, things are far more
difficult.  To port SYN to those earlier Macs is a project that is
probably too horrible to contemplate.  Both Perl and GNUPlot are flaky,
and the use of ":" as a path separator is a mess.


MS Win32 Windows

Perhaps the XP versions are the best choice; no attempt has been made
to try a variety of different versions of Windows.  To chase after MS
software whose design goals are new sales over downward compatability
is a mugs' game, for all that many earnest and talented open-source
developers play it.

If there is no development environment in place, there is an obvious
choice for installing Perl:  the `Strawberry Perl' package comes with a
working compiled version, but also includes the GNU C compiler for backup.
A straightforward installation of GNUPlot is available without X11.
The SYN tools can be used through a `command prompt' window, but the
facilities and documentation fall short of what a UNIX user would call
command `support,' so it will usually be necessary to work in tandem
with MS GUI file tools in one window and SYN tools through another `command
prompt' window.

The worst difficulty under MS Windows is that Perl scripts cannot be
executed directly.  Windows has no equivalent of the `shebang' (#!)
convention that labels a file as to be executed by giving it to a program
(like Perl).  The SYN tools themselves are not greatly inconvenienced by
this, since they can be run (and can run each other) as `Perl XXX' instead
of `./XXX' or `XXX'.  But when executable components are coded in Perl,
SYN needs to execute them in some way that is language independent.
(Other scripting languages have the same difficulty, but compiled
code--say from C--does not.)  Perl developers have a trick that should
work for other cases: a Perl script `runperl.bat' is provided that when
executed finds the name under which it was run, and runs Perl on a source
with that name.  So making file `XXX.bat' a copy of `runperl.bat' and then
typing `XXX' will have the same effect as typing `Perl XXX'.  But one must
remember to make this copy when a Perl program is created, sort of like
`compiling' the source code.  (Of course, the operation can take place
before such a Perl program exists--that's real magic compiling!--and need
not be repeated if the program should change without changing its name.)
As a part of the SYN tools, the script `perlx' performs this operation,
and has been run on itself (to make `perlx.bat') so that `perlx XXX' will
`compile' Perl script `XXX' for use.  If `XXX' fails, try `perl XXX' and/or
use `perlx XXX'.  Executability of component code comes up in using the
`COMP' script to approximate a component.  `COMP' tries to execute
the code and report any difficulties, but it can't do a very good job
across platforms.

A word about file names.  The underlying Windows OS forces all names
to upper-case and limits them to eight characters (of which only six
come from the real name if it's longer than eight) with an optional
extension set off by a `.'.  Don't go outside this convention unless
you want obscure file problems.  Since Windows uses the extension to
determine which program gets the file by double-clicking, and may create
those extensions (which are exceedingly difficult to remove!) without
cause, and may refuse to access files with some extensions (e.g.,
`.bin'), it is a good idea to avoid all extensions other than `.ccf' in
creating files, and for Perl code files there must not be an extension.
This means that one must be very careful how a file is created, since
most editors add their own extentions.  From the command prompt, the
`edit' program is an exception: it does what it's told to do.

A word about file format.  One of the most important insights that the
UNIX designers had is that all files are strings of characters, perhaps
broken into lines.  Any program may read or write any UNIX file without
concern for special format.  (Not that perverse programs cannot create
formatting, but unless they are truly evil they do so using printable
characters so that the format is visible on a screen or printer, and
may be examined or adjusted with a simple editor.)  The design (to
use the term loosely) of Windows turned this UNIX insight on its head.
It is almost as if the MS designers knew the truth of the matter and
made a conscious decision to pervert it.  They created special formats
for everything, formats that are proprietary secrets and which change
frequently with the express purpose of creating downward incompatability
(with the express purpose of selling `latest versions' of software).
This philosophy is very hard on a tool developer outside MS, because few MS
utilities can be used with new tools.  The utility program will put files
into its proprietary format silently, and only it can undo the mess it has
made (but why should it?!).  So tools must include excess functionality to
avoid MS software.  The SYN tools were developed on a shoestring budget
for UNIX, where the system utilities are trustworthy, so SYN includes
no utilities.  This makes file editing a nightmare.  A compromise is to
make use of MS utilities and put everything in `text' format (`.txt').
Then when SYN tools need to look at the files they can adjust the names
(and they don't have to adjust the format).  There are then two choices:
(1) Use `edit' from a command line, and avoid extensions except where
SYN requires them (notably in `.ccf' files).  (2) Use editors (e.g.,
`wordpad') and other programs that do not adjust the format of files of
type `.txt' and stick to this format.  With care, files can be created
in text format with an arbitrary extension, and once created, can be
edited and `save'ed with the extension unchanged.  But creation of a file
whose name has no extension is difficult; such a file can be edited and
`save'ed, but starts out as `.txt' on creation.  `perlx' copies a file
with extension to a bare name, which is not a bad compromise.
