evaluated load clauses

Bug #1953708 reported by Anton Vodonosov
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
CFFI
New
Undecided
Unassigned

Bug Description

Why are load clauses in define-foreign-library are not evaluated?

The need to know the paths at coding time is inconvenient. For example, it took some creative thinking to come up with a solution that allows cl+ssl user to customize the path.

Another use case is that we want to try some paths only if it exists. To do so we had to add a feature flag for every path and then use those features in the load clauses (https://github.com/cl-plus-ssl/cl-plus-ssl/commit/b6eda80a3e79459397085321bfb646f97bc6d848). It would be more natural to simply not pass the unexisting paths to the define-foreign-library.

The behavior of define-foreign-library is specified such that it seems to process the load-clauses at the program execution time (e.g. testing the features). So the load clauses could have been implemented as evaluated parameters.

Revision history for this message
Stelian Ionescu (sionescu) wrote :

I've been following https://github.com/cl-plus-ssl/cl-plus-ssl/issues/114 and I think the right way to approach is is to find the library path using pkg-config (the same as for a C project), and extract the path to the actual library.
I have code that works pretty well on Linux. If that could be ported to OSX, you could have this: https://github.com/sionescu/cl-plus-ssl/commit/a66c1be8d00a15e4813c9f718a7d5d7faefb01d2.

Revision history for this message
Anton Vodonosov (avodonosov) wrote (last edit ):

The current discussion in the cl+ssl issue 144 is about taking the library from alternative package managers, I am not sure will pkg-config be suitable for that or not.

Anyways, even if cl+ssl was able to find good OpenSSL automatically, it's necessary to have possibility for user to to override the OpenSSL path with his own value. The question with evaluated parameter remains.

The cffi-c-library ASDF component looks interesting, is it a part of mainstream CFFI or some experimental code? The foreign lib path it detects via pkg-config, is it frozen at build time, or determined dynamically during the program execution? I am also interested, because I was thinking of a similar, but simpler component type - simply declare that a system has foreign dependency, which would allow to collect a list of foreign dependencies for an application, maybe print some help about their installations.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.