[M3devel] building packages from source from cvs -- odbc
Daniel Alejandro Benavides D.
dabenavidesd at yahoo.es
Sat May 19 16:38:48 CEST 2012
Hi all:
if the .deb package doesn't overrides another location or content of .io files in another .deb then it shouldn't go inside the same PKG_ROOT but just as is any other non-Modula3 built library. But if they are, they should go to cm3 paths because you could require to re-link and generate updated packages from a specific location you choose from deb-src.
Something akin linux modules and kernel, if you compile a new module you need to rebuild against the kernel (isn't like that) to re-link and use. Normally this modules are just libraries and kernel is just compiled in very old stable kernels. That's what I learned from Ubuntu.
Thanks in advance
--- El vie, 18/5/12, Hendrik Boom <hendrik at topoi.pooq.com> escribió:
> De: Hendrik Boom <hendrik at topoi.pooq.com>
> Asunto: Re: [M3devel] building packages from source from cvs -- odbc
> Para: "m3devel" <m3devel at elegosoft.com>
> Fecha: viernes, 18 de mayo, 2012 18:29
> On Thu, May 17, 2012 at 06:01:19AM
> +0000, Jay K wrote:
> >
> > 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.
> > 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.
>
> Debian splits things up a lot more, and has explicit
> package-dependencies.
>
> There's usually an omnibus package the depends on all the
> others, for
> the simple souls who just want everything. Sometimes
> they are amazed
> how much everything entails. More often the don't
> notice. I, for
> example, got a complete set of video drivers for just about
> every
> video card ever made, as a result of installing one package
> I was
> actually interested in. Threatening to take one out (I
> didn't have
> that card) resulted in aptitude trying to remove my window
> manager.
> Clearly a poor situation. But that's what an
> all-inclusive policy can
> cause.
>
> In addition, there's a main package that contains everything
> you just
> couldn't do without, and you have to add other packages as
> you need
> them. For the video situation above, the user could
> take this approach,
> but it would require him to know just what hardware he had
> in his
> machine. Most users don't know this and don't care to
> find out.
>
> So applying this philosophy to Modula 3, it would probably
> end up
> split up at least as much as the multipackage offering on
> the download
> site. And these packages would have dependencies on
> one another, so
> you wouldn't end up installing one without its
> prerequisites.
>
> One package would clearly be the compiler and its minimal
> run-time
> system.
>
> Others would provide applications and libraries.
>
> And each libraries would be split further -- one package
> (perhaps
> called foo) that provides what you need to run a program
> using it, and
> another (foo-dev) that provides what you need to cmopile a
> program
> that needs it. THer are interested in making the disk
> requirements
> of a Debian system as small as possible. Even in C, if
> you aren't
> going to use a library for developmentt, you can get rid of
> a lot of
> h-files.
>
> It's quite possible for one source package to generate
> several binary
> packages, by the way.
>
> ---
>
> The other thing that separates our packages from ordinary,
> official
> Debian packages it that ours install everything to one place
> in the
> file system, and Debian follows a standard tthat spreads it
> all over
> the place.
>
> I'd have to learn and do a lot to get something acceptable
> to Debian.
> I certianly won't get it all done by the expected wheezy
> freeze in a
> few months, and, other things being important too, I may not
> get
> around to it at all.
>
> -- hendrik
>
> >
> >
> > Of course ultimately we don't want per-target stuff at
> all. :)
> > Or at least we want both "source" and "binary"
> distributions.
>
> -- hendrik
>
> >
> >
> > 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?
> > 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
> >
> >
> > > Date: Wed, 16 May 2012 22:35:33 -0400
> > > From: hendrik at topoi.pooq.com
> > > To: m3devel at elegosoft.com
> > > Subject: Re: [M3devel] building packages from
> source from cvs -- odbc
> > >
> > > On Wed, May 16, 2012 at 09:49:03PM -0400, Hendrik
> Boom wrote:
> > > > On Thu, May 17, 2012 at 12:06:00AM +0000, Jay
> K wrote:
> > > > >
> > > > > > ***
> LIBRARY_PATH shouldn't contain the current directory
> when
> > > > > > *** building
> gcc. Please change the environment variable
> > > > > > *** and run
> configure again.
> > > > >
> hendrik at april:~/cm3/cm3/scripts/python$
> echo $LIBRARY_PATH
> > > >
> > :/usr/local/Gambit-C/lib
> > > > > Please either clear the variable,
> or at least remove the leading :.The leading : makes there
> be an empty entry, which is interpreted as current
> directory, which is dangerous and fragile. I think.This is a
> local problem on your machine. Easily
> fixed. It might be reasonable for us to
> clear it in m3cc/src/m3makefile. - Jay
>
>
>
>
> > > >
> > > > Yes, emptying LIBRARY_PATH enabled uprade.py
> to complete successfully.
> > > > Thanks. It would have taken me many
> ages to figure this out.
> > > >
> > > > -- hendrik
> > > >
> > > Now I'm onto ./make-dist.py
> > >
> > > It fails in teh data base stuff.
> > >
> > > First becaues it didn't have libodbc. So I
> installed package unixodbc.
> > > But then:
> > >
> > > == package /farhome/hendrik/cm3/cm3/m3-db/odbc ==
> > >
> > > +++
> /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/bin/cm3
> -build -DROOT=/farhome/hendrik/cm3/cm3 +++
> > > --- building in AMD64_LINUX ---
> > >
> > > ignoring ../src/m3overrides
> > >
> > > ==> /farhome/hendrik/cm3/cm3/m3-db/odbc
> done
> > >
> > > +++
> /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/bin/cm3
> -ship -DROOT=/farhome/hendrik/cm3/cm3 +++
> > > --- shipping from AMD64_LINUX ---
> > >
> > > . =>
> /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/pkg/odbc/AMD64_LINUX
> > > .M3EXPORTS
> > > . =>
> /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/lib
> > > libm3odbc.so.5
> "/farhome/hendrik/cm3/cm3/m3-db/odbc/AMD64_LINUX/.M3SHIP",
> line 4: quake runtime error: unable to copy "libm3odbc.so.5"
> to
> "/tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/lib/libm3odbc.so.5":
> errno=2
> > >
> > > --procedure-- -line- -file---
> > > install_file
> -- <builtin>
> > >
> 4
> /farhome/hendrik/cm3/cm3/m3-db/odbc/AMD64_LINUX/.M3SHIP
> > >
> > > Fatal Error: package build failed
> > > *** execution of [<function
> _BuildGlobalFunction at 0x1a56de8>, <function
> _ShipFunction at 0x1a56c80>] failed ***
> > > hendrik at april:~/cm3/cm3/scripts/python$
> > >
> > >
> > > It doesn't seem to build libm3odbc.so.5
> > >
> > > hendrik at april:~/cm3/cm3/m3-db/odbc$ ls
> AMD64_LINUX/
> > > libm3odbc.a libm3odbc.so
> SQLext.mo SQLtypes.io
> > > libm3odbc.m3x SQLext.io
> SQL.io
> > > hendrik at april:~/cm3/cm3/m3-db/odbc$
> > >
> > > There's nothing at all in
> /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/pkg/odbc/AMD64_LINUX
> > > There are lots of files in
> /tmp/tmp_T7ITL/cm3-all-AMD64_LINUX-d5.9.0-20120516/lib,
> > > but nothing resembling libm3odbc>
> > >
> > > -- hendrik
> > >
> > >
> >
>
>
>
>
More information about the M3devel
mailing list