[M3devel] Installation package collections, was: Re: Missing packages, Was: missing M3_FRONT_FLAGS from libm3: m3overrides

Sun May 17 17:07:14 CEST 2009

Since Jay's touching the topic below, I thought I'd just tell you all
of the first attempt to bundle the M3 packages into installation
packages. I didn't want to end up with an installation package for
every M3 package, but maybe the granularity is still too coarse.
Currently I've got these:

% for c in min core devlib m3devtool m3gdb webdev gui anim database  
cvsup obliq juno caltech-parser demo tool math game; do echo; echo  
"collection $c"; fgrep " $c" scripts/pkginfo.txt | awk '{print $1}' >  
x-$c; cat x-$c; done

collection min # minimal m3 installation (together with the compiler)
import-libs
m3core
libm3

collection core # a usable system able to bootstrap itself with some  
additional libraries
import-libs
m3cc
m3core
libm3
patternmatching
sysutils
unittest
m3middle
m3objfile
m3linker
m3back
m3staloneback
m3front
m3quake
cm3
m3scanner
m3tools
m3cgcat
m3cggen
m3bundle
mklib
fix_nl
libdump
bitvector
digraph
parseparams
realgeometry
set
slisp
sortedtableextras
table-list
tempfiles
tcl
tcp

collection devlib # libraries for various development work
windowsResources
udp
libsio
libbuf
debug
listfuncs
m3tk-misc
binIO
commandrw
tapi
serial
m3tk
m3scan
m3markup
events
rdwr
PEX
deepcopy
sgml

collection m3devtool # M3 development tools complementing the compiler
cm3ide
m3totex
m3tohtml
m3browser
netobj
netobjd
stubgen
sharedobj
sharedobjgen
stablegen
stable
formsview
formsedit
recordheap
rehearsecode
replayheap
showheap
shownew
showthread
pp

collection m3gdb # the GNU debugger for M3 (rather large, so it has  
its own package)
m3gdb

collection webdev # web development packages
http
m3-www/web
m3-www/proxy
webvbt
deckscape
webscape
webcat

collection gui # gui libraries
import-libs
tcp
X11R4
ui
vbtkit
cmvbt
jvideo
videovbt
formsvbtpixmaps
formsvbt
formsview
formsedit
opengl
webvbt
kate
m3-ui/bicycle

collection anim # animation libraries, tools and demo
codeview
mg
mgkit
anim3D
zeus
m3zume
mentor

collection database # database packages and interfaces
odbc
postgres95
db
smalldb

collection cvsup # CVSup
cvsup/suplib
cvsup/client
cvsup/server
cvsup/cvpasswd

collection obliq # Obliq implementation
embutils
synloc
synex
metasyn
obliqrt
obliqparse
obliqprint
obliq
obliqlibemb
obliqlibm3
obliqlibui
obliqlibanim
obliqsrvstd
obliqsrvui
obliqbinmin
obliqbinstd
obliqbinui
obliqbinanim
obliqlib3D
visualobliq
vocgi
voquery
vorun

collection juno # The Juno graphical constraint-based editor
pkl-fonts
juno-machine
juno-compiler
juno-app

collection caltech-parser # Caltech parser generator
import-libs
cit_common
m3tmplhack
cit_util
term
paneman
paneman/kemacs
drawcontext
drawcontext/dcpane
drawcontext/kgv
hack
m3browserhack
parserlib/ktoklib
parserlib/klexlib
parserlib/kyacclib
parserlib/ktok
parserlib/klex
parserlib/kyacc
parserlib/kext
parserlib/parserlib
parserlib/parserlib/test

collection demo # some demo programs
cube
calculator
fisheye

collection tool # more or less useful tools
mtex
cmpdir
cmpfp
dirfp
uniq

collection math # mathematical libraries
arithmetic
unittest-numeric

collection game # games and game support
m3-ui/bicycle
m3-games/badbricks
m3-games/columns
m3-games/fours
m3-games/maze
m3-games/solitaire
m3-games/tetris

Comments welcome.

Olaf

Quoting Jay <jay.krell at cornell.edu>:

> I know this is a problem and not sure what to do about it.
>
>
> To backtrack, I think the original design is that the config file will
> put the libraries in system_libraries or system_liborder, and the m3makefile
> for the dependent packages will check for the presence in them.
>
> So, the reason I said "backtrack" is because this is another reason
> to edit config files, one that I haven't eliminated.
> You know, my config files are pretty good at being very portable,
> but not in this way. And they still have the lib/lib32/lib64 problem.
>
> Obviously pkginfo.txt wasn't in the original design. :)
>
> However the caltech/cit stuff is not this problem.
> The odbc/postgres stuff is.
> I generally go and do install the stuff, so I can build larger
> more featureful distributions. But you could classify that
> as the obligation of a distribution builder vs. a "normal" user.
>
> For caltech/cit, do this:
>
> cd to the root of source tree
> cvs -z3 upd -dAP
> rm scripts/PKGS
>
> and then try again.
>
> "all" I don't think works in general, for building.
> It works for "clean".
> "std" is the "all that works for buiding", I think.
> That is how I use them. But I still have a separate list of packages, oops.
> pylib.py doesn't yet read pkginfo.txt, oops.
> (This is an area where I complained about and fixed glaring
> redundancy in the sh files, and then put in my own similar
> redundancy, but also fixed the other.)
>
> Could be, simply, we define two package sets:
> all-that-tends-to-build-on-stock-systems
> all-with-extra-dependencies
>
> for some definition of "stock" -- does it include X Windows?
> I frequently hit missing X Windows stuff, but like with odbc/postgres
> I go and install it.
>
>
> Which devolves to:
>
> all-stock-nogui
> all-stock-gui
> all
>
> but this is getting messy and maybe go back to the original design.
> OR, maybe this isn't so bad -- you know, in the model where we
> have apt-get install modula3-this, apt-get install modula3-that,
> you do end up breaking it down into a lot of smaller pieces.
> Again I point to the example of what they did with X Windows.
> And maybe with KDE -- broken things down into many packages.
> Perhaps we should do that.
> ??
>
>
>  - Jay
>
>
> ----------------------------------------
>> Date: Sun, 17 May 2009 01:11:40 -0700
>> From: eiserlohpp at yahoo.com
>> To: m3devel at elegosoft.com
>> Subject: [M3devel] Missing packages, Was: missing M3_FRONT_FLAGS   
>> from libm3: m3overrides
>>
>> Hi Jay,
>>
>> Attached AMD64_LINUX (dated: 2008-10-30),
>> Unix.common (dated: 2008-10-30).
>>
>> Hmm, I guess, I have fallen into the Modula-3 config file
>> cess-pool.
>>
>>
>> Okay, I copied the config files to a temporary directory,
>> and the corresponding ones from the current source tree,
>> and diff'ed them.
>>
>> Quite a number of changes. I will grab the new config files from the
>> source tree, ... (hours pass), ..., okay things are working nicely.
>>
>> It failed midway through, complaining that it could not find
>> a certain library. I don't want to install that library, so...
>>
>> I had to remove a couple lines from $ROOT/scripts/pkginfo.txt,
>> specifically odbc, and while I was at it postgres95, I know I
>> don't have Postgress95. That allowed me to build "std".
>>
>> So, then I decided to build everything with "do-cm3-all.sh",
>> and I got an immediate:
>>
>> package cit_common not found
>> *** cannot find package cit_common /
>>
>> Okay, back to editing pkginfo.txt, and removing cit_common, and while
>> I am at it all the caltech parser packages. Darn, I was hoping to play
>> with those.
>>
>> We need to document the fact that we have a number of bindings to
>> libraries that may not exist on any particular machine, and when
>> that occurs, the pkginfo.txt file should be edited to remove those
>> packages from being compiled.
>>
>>
>> Peter
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> +--------------------------------------------------------+
>> | Peter P. Eiserloh |
>> +--------------------------------------------------------+
>>
>>
>> --- On Sat, 5/16/09, Jay wrote:
>>
>>> From: Jay
>>> Subject: RE: [M3devel] missing M3_FRONT_FLAGS from libm3: m3overrides
>>> To: eiserlohpp at yahoo.com, "m3devel"
>>> Date: Saturday, May 16, 2009, 2:52 PM
>>>
>>> Peter can you can roughly
>>> backup your config file
>>> send me/us your config file (attachment to m3devel ok)
>>> cp src/cm3/m3-sys/cminstall/src/config-no-install/*
>>> /usr/local/cm3/bin
>>>
>>> ?
>>>
>>> cm3.cfg might be in the neighboring config directory.
>>>
>>> I'm not entirely comfortable with the user-editability of
>>> config files and you seem to have either a user-edited one
>>> or an old one.
>>>
>>>
>>> Or did you start from scratch and run cminstall?? I don't
>>> think so but not sure.
>>>
>>>
>>> The user-editability of config files is partly to allow
>>> adapting to inevitably local conditions but I think also a
>>> bit of a cop-out to not encode things in cm3.
>>> If you correlate the number of questions cminstall asks
>>> with the editability of the config file, compare that to the
>>> number of questions or amount of editing or command line
>>> parameters typically involved with ./configure or apt-get
>>> install (often those are zero).
>>>
>>> In my own "programming", the config files are a cop out
>>> related to my lack of comfort with Modula-3.
>>>
>>> - Jay
>>>
>>>
>>> ----------------------------------------
>>>> Date: Sat, 16 May 2009 11:55:03 -0700
>>>> From: eiserlohpp at yahoo.com
>>>> To: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] missing M3_FRONT_FLAGS from
>>> libm3: m3overrides
>>>>
>>>>
>>>> Jay,
>>>>
>>>> Thank you Jay for looking into this. Oops, you are
>>> right
>>>> s/obliq/quake/.
>>>>
>>>> BTW: It builds all the way even in the same source
>>> tree when I do an "./scripts/upgrade.sh", I did a
>>> "realclean" first. I guess this
>>>> (upgrade.sh) is what most people are using these days
>>> to build the
>>>> compiler, rather than the old "do-cm3-foo" scripts.
>>>>
>>>> Okay, I downloaded
>>> cm3-src-all-d5.8.0-2009-05-16-12-07-46.tgz,
>>>> and did an upgrade.sh, then after a "do-cm3-std.sh
>>> realclean",
>>>> I re-tryed the "do-cm3.std.sh build", and it failed
>>> again with
>>>> the same error. This is with cm3 (5.8.0) built with
>>> this mornings
>>>> source tree.
>>>>
>>>> I inserted your change into libm3/src/m3override, and
>>> it is currently
>>>> building.
>>>>
>>>>> The file now reads:
>>>>>
>>>>> override("m3core", ROOT & "/m3-libs")
>>>>> if defined("M3_FRONT_FLAGS")
>>>>> M3_FRONT_FLAGS += "-vsdebug"
>>>>> else
>>>>> M3_FRONT_FLAGS = ["-vsdebug"]
>>>>> end
>>>>> _M3BUNDLE_OVERRIDE = "T"
>>>>
>>>> This is worked for me. I suggest you check it into the
>>> repository.
>>>>
>>>>
>>>> Peter
>>>>
>>>>
>>>>> From: jay.krell at cornell.edu
>>>>> To: eiserlohpp at yahoo.com; m3devel at
>>> elegosoft.com
>>>>> Subject: RE: [M3devel] missing M3_FRONT_FLAGS from
>>> libm3: m3overrides
>>>>> Date: Sat May 16 00:27:08 CEST 2009
>>>>>
>>>>> specifically:
>>>>>
>>>>>
>>>>> C:\dev2\cm3.2\m3-sys\cminstall\src\config-no-install\cm3cfg.common
>>>>>
>>>>>
>>>>>
>>>>> if equal(M3_BACKEND_MODE, "0") or
>>> equal(M3_BACKEND_MODE, "1")
>>>>> or equal(M3_BACKEND_MODE, "IntegratedObject") or
>>> equal(M3_BACKEND_MODE, "IntegratedAssembly")
>>>>> M3_FRONT_FLAGS = ["-unfold_nested_procs",
>>> "-check_procs"]
>>>>> % --- internal configuration options passed
>>> directly to the Modula-3 front-end
>>>>> else
>>>>> M3_FRONT_FLAGS = [ ]
>>>>> end
>>>>>
>>>>>
>>>>> - Jay
>>>>>
>>>>
>>>>
>>>>
>>> +--------------------------------------------------------+
>>>> | Peter P. Eiserloh |
>>>>
>>> +--------------------------------------------------------+
>>>>
>>>>
>>>>
>>
>>
>>

-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194