On Wed, 2006-08-30 at 19:56 -0400, Peter Tanski wrote:
> On Aug 30, 2006, at 4:00 PM, skaller wrote:
> By "everything," I meant everything Felix (or the module) needs,
> specified as search paths within the flx_pkgconfig. For Felix
> modules this would be an extra field, such as
>
> use_path:
>
> which would substitute for setting the path variable on the command
> line to flx_pkgconfig (a substitute to modifying $PATH) and would
> essentially operate like the argument --path= .
I don't understand where these paths would go.
The difficulty here is: each platform/installation/user has
a different set of paths.
In principle, we just place the burden on the user to specify them,
eg with some configuration data in some fixed place that can
be queried during configuration.
The problem is the building and installation mechanism has
to be 100% automatic. To build on the Debian autobuilder
for example, we can't stop and ask "where are your
resources kept?"
With Debian, we COULD say: Felix depends on "flxconfig"
package which when installed provides standard locations
for resources in /etc/felix/resh.locations, and if you
don't like them .. edit them BEFORE installing Felix.
The problem again is that the Debian autobuilder can't :)
To build Felix on Windows, you have to set up your
environment variables so MSCV++ finds the libraries.
Basically the key problem is how to have something
which is
(a) persistent -- Felix doesn't clobber it
(b) generated -- Felix can generate sensible defaults
(c) modifyable -- the user can change it
(d) extensible -- both Felix and third parties can extend
(e) changeable -- new versions use different layouts
.. all at the same time :)
A mechanism similar to what you describe is present
in flxcc control files, used to control automatic
generation of Felix bindings to C libraries.
The problem is of course that this makes these
files non-portable, so they can't be distributed.
The fact is that they're describing something
which is indeed non-standard .. even on Debian
systems developers often have repository based
source code builds of packages they're interested in.
> > The problem is how to create the *.fpc files:
> >
> > Here is config/mpi.fpc:
> >
> > cflags: -I/usr/lib/mpich/include
> > provides_dlib: -lmpi
> > provides_slib: -lmpi
> >
> > The cflags are correct .. the libraries aren't yet,
> > a -L switch is required. Problem is, the libraries
> > aren't called
> >
> > libmpi.so
> >
> > they're actually called:
> >
> > /usr/lib/mpich/lib/libpmpich.a
> > /usr/lib/mpich/lib/shared/libmpich.so
> >
> > This is because the libraries reflect the MPI implementation model.
> > There are more of them .. but who would ever guess these locations?
>
> When configuring mpich2, the configure script (or Debian package)
> should have logged the install sub-location--the part that comes
> after --prefix= . Couldn't you search for $prefix and use that setting?
Search where and for what?
If Felix 'resource' names were *required* to be Debian package
names it might be possible to use Debian tools to discover
where things are .. but then the location would simply
be hard coded in the configuration script.
> What about adding a flx-config variable, such as:
>
> FLX_CONFIG_FILE=/full/path/to/config/file/flx_config.fpc
> or
> FLX_CONFIG_DIR=/full/path/to/config/file
>From the source code:
var path=getenv("PKG_CONFIG_PATH");
Doesn't help much .. flx_pkgconfig isn't built yet :)
Maybe the thing to do is separate Felix *core* from
third party tools, to ensure it IS built by the time
deviant packages are installed.
I'm not sure the current build system can handle that.
At present there are phases of building .. but the phases
are based on requirements of cross compilation.
Consequently, there's even if A depends on B, the
configuration of A is done after that of B, but A
itself isn't built.
Host tools are built before target tools.
There is no separate 'configuration' phase: there
IS a 'build' phase though (nothing happens in it at
the moment).
> Felix already stores flx.fpc in the /usr/local/lib/felix/felix-
> [version]-[build] directory; it might be nice to relocate that to,
> say, the user's home directory under ~/.felix , then store all module
> files there. (Keeping the config in a system directory prohibits me--
> and any felix package install--from modifying it, unless I have root
> authority.)
Yes. Worse, you can't even compile installed examples,
because the compiler(s) don't allow 'shadow' writable directories.
Something along the lines of what you suggest must indeed
be done, but it is hard to know what.
You can already override flx_pkgconfig.. I've never tested
this though.
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Felix-language mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/felix-language
