On Aug 31, 2006, at 2:01 AM, skaller wrote:
> 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.
Why not add these things as ./configure flags? For each particular
user's system there may be special C programs they want to include
but that would be a *big* goal. Generally the build problem would be
for developers compiling Felix and Felix would have a stable set of
modules it would either use from the current system (if they exist)
or build as part of the distribution, such as GMP. For a stable set
of modules, configure flags would work, i.e., --have-gmp=/usr/
local . This is standard autotools stuff. For a more "automatic"
system, have a standard set of search paths per system (this might be
a ./configure flag, such as --use-windows-dirs, --use-posix-dirs),
where for a finite set of directories the configure could search for
systems available and place its results in a .fpc file.
> 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
Set a default in the configure to use whatever is available--you used
to have that when you kept config.py if it existed.
> (b) generated -- Felix can generate sensible defaults
A standard set of search paths (as with the --use-windows-dirs
example, above, where standard directories might be /Program\ Files;/
minGW;etc.)
> (c) modifyable -- the user can change it
Put flx_config.fpc in the user's home directory, under .felix (on
Posix); in the registry on Windows.
> (d) extensible -- both Felix and third parties can extend
Third parties could view a flx_config.fpc in a user's home directory
or the Windows registry; it doesn't matter as long as it is *standard*.
> (e) changeable -- new versions use different layouts
This requirement seems to kill all the others, particularly (a),
since it implies the configuration system *must* clobber any
persistent header. The balance seems to be the Felix-system
developer's ability to define new build settings and the user's
ability to keep them. While backward-compatibility may a hassle, why
not just define a standard and stick with it as long as possible?
> 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 key to portability is standardisation: if they want to be non-
standard, it should be possible to work around it, but generally
users should stick with the standard. What you seem to be developing
here is your own Felix distribution system. That is a simple pain
everywhere. On OS X, there is a distribution system for Fink, there
is another for DarwinPorts, there is chaos for systems that package
programs as .dmg files--it's a mess because no one sticks to the
standard (Apple has already defined this for its system
directories). The point is, the burden is on developers to stick to
the relevant system standard, not users.
>>> 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?
I guess you already answered this question above, with searching
system directories for C packages Felix uses. Outside of that I
answered the question for other (say, legacy Felix) modules.
> 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");
Don't rely on an environment variable.
(1) it pollutes the user's environment with yet another variable
(2) users who don't read directions first and simply type ./configure
may miss it
Use ./configure flags and print out a ./configure --help; use
standard directories by default.
> Doesn't help much .. flx_pkgconfig isn't built yet :)
For new builds none of this should be a problem, except for C
packages the user has in nonstandard directories (outside of /usr, ~/
usr, say), at which point users should be able to resort to ./
configure --have-pkg=...
> 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.
Staged builds seem to be the method of choice for compilers, but some
interdependencies remain. For example, with GHC the RTS requires GMP
to be (a) present in the system or (b) built before the RTS.
> 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.
What can you separate out? Is this problem due to OCaml? The OCaml
restriction that all libraries must be built statically (to guarantee
type safety across modules) is one of the worst design flaws of the
language--it virtually obliterates any large distributable systems
because everything must be rebuilt if you change something at the
beginning. (For small systems you don't care, you simply
redistribute a stand-alone executable and possibly a few libraries,
but in this day of insecurity you should leave an opening for easy,
small updates.)
> There is no separate 'configuration' phase: there
> IS a 'build' phase though (nothing happens in it at
> the moment).
I think that is another key problem. There should be separate
configuration phases (taking precondition parameters from the
master ./config, of course) for each third-party application.
>> 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.
Is that why you have to use 'make virgin' every time you want to
rebuild? Why is that? Can't the system follow symbolic links?
-Pete
-------------------------------------------------------------------------
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
