<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
I know I'm guilty, and I'm a little on the fence.<BR>
<BR>
<BR>
I think /maybe/ we should have<BR>
m3-sys/cminstall/src/config-no-install/Solaris.libraries<BR>
m3-sys/cminstall/src/config-no-install/Linux.libraries<BR>
m3-sys/cminstall/src/config-no-install/NetBSD.libraries<BR>
m3-sys/cminstall/src/config-no-install/OpenBSD.libraries<BR>
m3-sys/cminstall/src/config-no-install/FreeBSD.libraries<BR>
m3-sys/cminstall/src/config-no-install/IRIX.libraries<BR>
m3-sys/cminstall/src/config-no-install/HPUX.libraries<BR>
etc.<BR>
<BR>
and in packages we'd copy one of these to<BR>
/usr/local/cm3/bin/config/cm3cfg.libraries <BR>
<BR>
<BR>
so that we'd maintain the "codify the 'standard' locations" while also easing custom editing.<BR>
<BR>
<BR>
More generally there's probably install/cm3/bin/config/libraries/*.quake.<BR>
X11.quake <BR>
c.quake <BR>
ODBC.quake <BR>
z.quake <BR>
<BR>
possibly install/cm3/bin/config/libraries/TARGET/*.quake.<BR>
<BR>
possibly probe between them.<BR>
<BR>
Each one or two lines.<BR>
<BR>
m3makefile dependent on ODBC would read:<BR>
<BR>
UseLibrary("X11")<BR>
and/or<BR>
UseLibraries(["X11", "ODBC"])<BR>
<BR>
proc UseLibraries(a) is<BR>
foreach b in a<BR>
local c = CONFIG_ROOT & "/" & a & ".quake"<BR>
if exists(c)<BR>
include(c)<BR>
else<BR>
print("WARNING: not building package " & package_name & " because library " & a " is missing)"<BR>
inform_cm3_to_skip_current_directory()<BR>
end<BR>
end<BR>
<BR>
proc UseLibrary(a) is UseLibraries([a]) end<BR>
<BR>
<BR>
cm3 and scripts would have switches like:<BR>
-error-for-missing-libraries<BR>
-error-for-missing-library:X11<BR>
-ignore-missing-libraries <BR>
-ignore-missing-libraries:X11,ODBC <BR>
-ignore-missing-library:X11<BR>
<BR>
and where I have print above, well, more like:<BR>
inform_cm3_of_missing_library(a)<BR>
<BR>
but for that matter, move all the logic to cm3 probably.<BR>
Probably should be using Modula-3 more and Quake less.<BR>
But it's just so adequate and reasonably pleasant.. <BR>
<BR>
<BR>
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?<BR>
(The keys in one should be the members in the other and vice versa).<BR>
??<BR>
<BR>
There are like three main scenarios I think.<BR>
- It is a "package" available on the system, and therefore in a known platform specific location on the vast majority of systems.<BR>
e.g. /usr on Debian, /usr/pkg on NetBSD, /usr/local on FreeBSD, /usr/sfw or /opt on Solaris.<BR>
<BR>
- 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 <BR>
- Sometimes this is the same as the first.<BR>
<BR>
- User builds it from source and it goes to the system owner's preference. <BR>
<BR>
I have really only catered to the first.<BR>
And since I emphasize folding common code, the other two have suffered.<BR>
<BR>
There is also the possibility of knowing about "pkgconfig".<BR>
Which only solves the problem for packages that use it.<BR>
<BR>
Similarly I'm on the fence regarding autoconf and/or its approach.<BR>
Autoconf seems quite messy and slow, but doing similar sorts of things in Quake hasn't seemed so bad.<BR>
<BR>
<BR>
- Jay<BR><BR> <BR>> Date: Thu, 20 Aug 2009 17:07:37 +0200<BR>> From: wagner@elegosoft.com<BR>> To: m3devel@elegosoft.com<BR>> Subject: Re: [M3devel] SYSTEM_LIBS, quake, ./configure<BR>> <BR>> Quoting Dragi¹a Duriæ <dragisha@m3w.org>:<BR>> <BR>> > In this ticket, https://projects.elego.de/cm3/ticket/1048, cvsup problem<BR>> > with libz on some systems is described. But, that problem is bigger than<BR>> > this - whole C portability issue.<BR>> ><BR>> > We need quake standardized way for locating (or not allocating:) system<BR>> > libraries. That way, it'll be possible to have Modula-3 programs and<BR>> > libraries which depend on C libraries like.... expat, tidy, mysqlclient,<BR>> > sqlite... distributed as wide as cm3 is.<BR>> ><BR>> > This is solvable with some quake magic?<BR>> <BR>> This kind of configure-function was part of the old CM3 installer,<BR>> but has become unused now, because Jay insists that it is unnecessary.<BR>> I don't think this should be a quake function executed at compile time.<BR>> Interfaces to a well-known set of system libraries are contained in<BR>> the config files.<BR>> <BR>> A quake definition of such a function would necessarily be system-<BR>> dependent, as it would need to know about all standard locations to<BR>> search on a certain platform. Or search all known locations, but then<BR>> the problem of resolving multiple hits comes up...<BR>> <BR>> Olaf<BR>> -- <BR>> Olaf Wagner -- elego Software Solutions GmbH<BR>> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany<BR>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95<BR>> http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin<BR>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194<BR>> <BR></body>
</html>