[M3devel] building packages from source from cvs -- odbc

[Hendrik Boom]

On Thu, May 17, 2012 at 06:01:19AM +0000, Jay K wrote:
> 
> Good.
> Wasn't the error message from configure obvious though?

Evidently not.  Or I was too much asleep last night.  Or I didn't get 
one. I'm looking for one now.  I find none in my most recent script 
output.  In one of the old ones I find

checking for modern makeinfo... no
configure: WARNING:
*** Makeinfo is missing or too old.
*** Info documentation will not be built.
checking for recent Pod::Man... yes

but I suspect that may be irrelevant.  Unless packageing fails later 
because it tries to package the info docs, which I hate anyway.

No, I don't find any messages.  But then, I'm simply using my old, 
working cm3 compiler as a bootstrap to build the whole system for the 
same machine.  I didn't have a specific 'configure' step.

I found a bunch of compilation warnings about
* labels and other names  being defined but not used.
* comparisons always false due to limited range of data type
* invalid conversion type characters.  Might these actually cause 
run-time failures?
* right-hand operand of comma has no effect

These are unlikely to be the problems I'm contending with, but might 
it be worth going through the entire build sometime and tracking 
then all down?  Grepping my script output for "warning" would 
probably find them all.


> 
> 
> Anyway:
>   I think there's a "minor" incrementality bug here.   
>   Incremental build isn't picking back up where it left off/failed.  
> 
> Try this:
>    rm -rf /farhome/hendrik/cm3/cm3/m3-db/odbc/AMD64_LINUX   
>    rm -rf /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516 
>    ./make-dist.py  

Will do.  I had planned to do something like this when I was awake this 
morning, but I was unsure just which files needed to be deleted.

> 
> 
> OR:  
>    rm -rf /farhome/hendrik/cm3/cm3/m3-db/odbc/AMD64_LINUX   
>    Look at make-dist.py/pylib.py -- get it to point at the same output as before and then just:  
>   ./make-dist.py 
> 
> 
> 
> That is -- I think every run of make-dist.py is clean to a new temporary timestamp-based location.
> This is good and bad.
> 
> 
> Note also, I think it is obvious, but I wrote make-dist.py to always package up everything possible
> for the target platform. So it is up to you as the "builder" to have all the dependencies already installed.
> It isn't great.
> I don't believe there is a perfect option here.
> Another release form we have yields a bunch of per-target packages.

This is the way other languages have gone in Debian.  The main reason 
seems to be to reduce the amount of other packages that have to be installed via 
dependencies that the user might not have any interest in.  Essentially 
a distinction between the language, the applications, and the 
libraries.  Something like what Modula3 does with its tgz'ed 
binary "packages".

> I find that confusing -- too many.
> My form yields just one largeish per-target package.
> Over-size, monolithic, but simpler, less choices to confuse people.
> 
> 
> Of course ultimately we don't want per-target stuff at all. :)
> Or at least we want both "source" and "binary" distributions.
> 
> 
> Still I am confused.
> Don't people have binary distributions of programs with GUIs for Linux?
> Like Komodo IDE, Komodo Edit, Acrobat Reader?
> 
> 
> Maybe we should really have a java-generating backend...one binary distribution for all..and a better Android story?

That could be useful on Android.  But it *is* possible to get package C 
or at least C object code to run on Android.  I think that's the 
approach being used to get Python to run on Android.

> I know, there is a funny tradeoff here. Modula-3 is kind of lower-level than Java.
> You'd want such a backend/port to throw out our garbage collector..and heck..all unsafe code....
>  (or generate C for those and use JNI or such...interesting..theoretically possible..unlikely to happen..)
> 
> 
>  - Jay