[M3devel] Missing packages, Was: missing M3_FRONT_FLAGS from libm3: m3overrides

Jay jay.krell at cornell.edu
Sun May 17 11:39:26 CEST 2009


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 |
>>>
>> +--------------------------------------------------------+
>>>
>>>
>>>
>
>
>


More information about the M3devel mailing list