[M3devel] SYSTEM_LIBS, quake, ./configure

[Jay K]

I know I'm guilty, and I'm a little on the fence.

 

 

I think /maybe/ we should have

 m3-sys/cminstall/src/config-no-install/Solaris.libraries

 m3-sys/cminstall/src/config-no-install/Linux.libraries

 m3-sys/cminstall/src/config-no-install/NetBSD.libraries

 m3-sys/cminstall/src/config-no-install/OpenBSD.libraries

 m3-sys/cminstall/src/config-no-install/FreeBSD.libraries

 m3-sys/cminstall/src/config-no-install/IRIX.libraries

 m3-sys/cminstall/src/config-no-install/HPUX.libraries

etc.

 

and in packages we'd copy one of these to

  /usr/local/cm3/bin/config/cm3cfg.libraries 

 

 

so that we'd maintain the "codify the 'standard' locations" while also easing custom editing.

 

 

More generally there's probably install/cm3/bin/config/libraries/*.quake.

  X11.quake 

  c.quake  

  ODBC.quake 

  z.quake 

 

possibly install/cm3/bin/config/libraries/TARGET/*.quake.

 

possibly probe between them.

 

Each one or two lines.

 

m3makefile dependent on ODBC would read:

 

UseLibrary("X11")

and/or

UseLibraries(["X11", "ODBC"])

 

proc UseLibraries(a) is

  foreach b in a

    local c = CONFIG_ROOT & "/" & a & ".quake"

    if exists(c)

     include(c)

    else

      print("WARNING: not building package " & package_name & " because library " & a " is missing)"

      inform_cm3_to_skip_current_directory()

   end

end

 

proc UseLibrary(a) is UseLibraries([a]) end

 

 

cm3 and scripts would have switches like:

  -error-for-missing-libraries

  -error-for-missing-library:X11

  -ignore-missing-libraries 

  -ignore-missing-libraries:X11,ODBC  

  -ignore-missing-library:X11

 

and where I have print above, well, more like:

   inform_cm3_of_missing_library(a)

 

but for that matter, move all the logic to cm3 probably.

  Probably should be using Modula-3 more and Quake less.

    But it's just so adequate and reasonably pleasant.. 

 

 

As well, need to consider what the "two level" aspect of the current design allows for and how to preserve that. I think it is "how to link library FOO" and "what global order to link libraries in". What I find ambiguous is code that checks for presence in SYSTEM_LIBORDER or SYSTEM_LIBRARIES. Seems to me like, probably, their members should always be the same?

(The keys in one should be the members in the other and vice versa).

??

 

There are like three main scenarios I think.

  - It is a "package" available on the system, and therefore in a known platform specific location on the vast majority of systems.

     e.g. /usr on Debian, /usr/pkg on NetBSD, /usr/local on FreeBSD, /usr/sfw or /opt on Solaris.

    

  - It may or may not be an available package and user builds it from source and it goes to the library owner's default, usually /usr/local 

     - Sometimes this is the same as the first.

 

  - User builds it from source and it goes to the system owner's preference. 

 

I have really only catered to the first.

And since I emphasize folding common code, the other two have suffered.

 

There is also the possibility of knowing about "pkgconfig".

  Which only solves the problem for packages that use it.

 

Similarly I'm on the fence regarding autoconf and/or its approach.

Autoconf seems quite messy and slow, but doing similar sorts of things in Quake hasn't seemed so bad.

 

 

 - Jay

 
> Date: Thu, 20 Aug 2009 17:07:37 +0200
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] SYSTEM_LIBS, quake, ./configure
> 
> Quoting Dragiša Durić <dragisha at m3w.org>:
> 
> > In this ticket, https://projects.elego.de/cm3/ticket/1048, cvsup problem
> > with libz on some systems is described. But, that problem is bigger than
> > this - whole C portability issue.
> >
> > We need quake standardized way for locating (or not allocating:) system
> > libraries. That way, it'll be possible to have Modula-3 programs and
> > libraries which depend on C libraries like.... expat, tidy, mysqlclient,
> > sqlite... distributed as wide as cm3 is.
> >
> > This is solvable with some quake magic?
> 
> This kind of configure-function was part of the old CM3 installer,
> but has become unused now, because Jay insists that it is unnecessary.
> I don't think this should be a quake function executed at compile time.
> Interfaces to a well-known set of system libraries are contained in
> the config files.
> 
> A quake definition of such a function would necessarily be system-
> dependent, as it would need to know about all standard locations to
> search on a certain platform. Or search all known locations, but then
> the problem of resolving multiple hits comes up...
> 
> Olaf
> -- 
> 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
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090821/fade2d57/attachment-0002.html>