What's in store in later revisions of Phil? This is a list of things that might be added or improved.
This is tentatively done as of release 0.5. Awaiting user feedback.
Phil should figure out how to run the linker to create shared libraries.
The difficulty in this is that the semantics of creating shared libraries differ from linker to linker. I don't mean that the command line options differ; that'd be an easy difficulty to handle.
The problem is how programs which link with shared libraries find the libraries when they are loaded. That differs from system to system, & each system offers a lot of options: loading only the exact library in the exact location it was in when the program was linked; searching a list of alternate locations that was available at link time; or searching a list of alternate locations that is determined at load-time. What's more, the searches can modify each other. For example, on some OS with some linker (Linux with Gnu ld, I think), the alternate paths are determined at run-time, but only those listed as alternate paths at link-time are used. (So it's the intersection of the set of paths available at run time & the set of paths available at load-time.)
Also, I think that only the first strategy, loading at run-time exactly the same file that was linked by ld, is safe. Should Phil reflect that belief & impose it on other developers?
With libtool, we can specify paths in which to search for installed libraries with the -R command line switch. It also looks like we must specify all the paths for all the libraries an app links with. So we need a way to determine all those paths. It looks like even /usr/local/lib is not searched automaticaly.
Provide an alternative way to use Phil in other software. In the alternative, Phil is included as part of the other package's distro. Replacing a package's included Phil with a later Phil needs to be effortless. Would be extremely cool if the Phil part of the distro could auto-determine whether the system already had Phil installed. If it did, we'd compile & link against that. If it didn't, we'd compile & link with the distro's Phil but without installing Phil as a library on the system.
Will there be licensing problems?
The world needs a system-independant, encoding-independant interface to characters & strings that might be multi-byte, or wide or whatever. Basically, an interface to different character sets.
No, C++ STL's basic_string
doesn't quite cut it, though it's a nice
try.
I don't know if this belongs in Phil, though.
Port Phil to Winders so that code for Unix can compile & run on it? Yes, Windows NT claims or claimed POSIX compatibility, & that might even be the truth, but the fact is that with Visual C++ 6.0, many fairly simple programs for Unix do not compile & run.
Port to Mac?