On 3/04/11 7:51 PM, Tristan Gingold wrote:
> It would be nice to have a nice MacOS-X installer, but I have no experience
> with that.
Mac OS X Installation
---------------------
I'll generate a disk image distribution file with an archive of the stripped
/usr/local/ghdl hierarchy. It will include top level access to ghdl.html.
There'll be a readme describing install/uninstall/build scripts, mounted
disk image invocation of install and uninstall scripts as applications and
how to build a disk image. The readme would note exception cases and
specify how to build different revisions. Revision information may be
passed in execution environment or as an argument (I'll see which is
prettier). The readme would also include information on how to manipulate
the build process. Re-targeting install locations is done through the build
process.
Two functions would be provided in the disk image distribution. Install
ghdl and Uninstall ghdl. These would appear as apps in the distribution.
A distribution is targeted to /usr/local/ghdl (without /build) and stripped of
all *.o *.ads *.adb *.ali *.o *.S directories .svn *.in *.inc Makefile and
directories /usr/local/ghdl/{ortho,psl, debug,xtools} and
/usr/local/ghdl/translate/{gcc, grt, mcode}
The build location concurrency with installation location is necessary to
avoid manipulating or replacing any ghdl svn repository files. The
alternative would be a maintained ghdl/translate/ghdldrv/Makefile.MacOSX.
The Prefix string in ghdl/translate/ghdldrv/default_pathes.ads specifies the
location of the ghdl libs. Builds of the ghdl libs are done relative to
ghdl/translate/ghdldrv. The common denominator is the Makefile.
A script would be used to build in /usr/local/ghdl or
/usr/local/ghdl/build/ghdl for someone wanting to build from source. There
would be nothing preventing a different install/build location. The same
script would execute from different locations or with different argument.
The build script will specify darwin targets for translate/ghdldrv/Makefile
make and make install.mcode, and remove
translate/ghdldrv/ortho_code-x86-flags.ads.
A script would be used to install either from /usr/local/ghdl or
/usr/local/ghdl/build/ghdl. The installation process creates (overwrites)
links:
translate/ghdldrv/ghdl_mcode /usr/local/bin/ghdl
doc/ghdl.1 /usr/local/man/man1/ghdl.1
ghdl.info to /usr/local/share/info
ghdl.info is provided as part of the distribution without proffer to build.
A script would be provided that could be used to either uninstall the
distribution, the build or both. part of that would include removing the
above links.
There'd be a script to strip the distribution directory and optionally the
build directory and create a disk image (.dmg file)
The disk image would contain the distribution archive, README, ghdl.html,
install script and uninstall script capable of being executed from the disk
image as apps.
The archive would contain copies of above scripts plus the build script,
README_MAC_OS_X, ghdl/doc, ghdl/libraries (source), ghdl/translate/libs and
ghdl/translate/ghdldrv/ghdl_mcode. A copy of ghdl.info would be provide as
well.
I would originally target ghdl Revision 142.
I've tested all this. Just need to formalize the scripts and build the disk
image, work out the details of permissions and what to do when things
already exist.
A ghdl mcode distribution would be around 6.3 MB and wouldn't require
manipulation of your execution environment to use.
Installing gktwave is outside the scope of this effort as well as installing
GNAT to use in building the ghdl mcode version. There would be no direct
dependencies on Xcode or Macports, just the existence of the compilers (gnat
Ada and gcc object file compatible). The read me would include some basic
hints on building.
Correcting any script errors due to ghdl changes is a predicate act for
creating a disk image. Ghdl is free to evolve. Building a Mac OS X
distribution is a freestanding issue.
This isn't actually a Mac OS X installation. There are no dependencies on
Library files and no installation registration, meaning the uninstall
app/script should be used for removal. This isn't a real Mac OS X
application and the amount of additional work is burdensome for no benefit
while GPL licensed programs are not eligible for App Store inclusion because
of requirements placed on a distributor. The read me in the disk image
would also provide information on how to remove ghdl manually (two links and
the /usr/local/ghdl hierarchy).
I'm contemplating an environmental variable to allow preexisting
/usr/local/ghdl, /usr/local/bin/ghdl, /usr/local/share/info/ghdl.info and
/usr/local/man/man1/ghdl.1 overwrites in the case of a conflicting
installation. In effect the installation could be non-invasive. Conflicts
could also be resolved by re-targeting the build.
I see no particular advantage to an Xcode or Macports build environment. If
and when I get to a ghdl front end version this would likely remain true.
Build environment dependencies are guaranteed to be out of sync with ghdl
releases.
The idea is to empower anyone to be able to follow, modify or build on this
process. (Because who knows, someday the horse may sing - Apple may allow
GPL programs in App Stores or we could end up with a real IDE or a WebKit
implementation).
Installation would at least initially require administrative privilege.
GHDL Code Map
-------------
I've gotten about 10 pages into describing the structure of ghdl. I think
it will take around 50 to 60 to be of use. There's lots of overhead, two
views, a top down view from Ada_main through command invocation and options
specification, covering just over three thousand lines of code and a code
function view outlining the rest. It will basically provide hints on where
to look in the code. FreeLibre/OpenOffice .odt file format plus I can
provide a PDF. I'd like to provide supplemental information on the front
end version as well as the mcode version, maybe another 10 - 15 pages.
I can also imagine an ghdl IIR reference. A code generation reference would
allow re-targeting from x86, ghdl could probably do with an abstraction
layer (for those IOS or Android afficionados).
_______________________________________________
Ghdl-discuss mailing list
[email protected]
https://mail.gna.org/listinfo/ghdl-discuss
