Re: [asdf-devel] ASDF's MAKE-BUILD breaks ECL's DLL target
On Thu, Jun 27, 2013 at 11:59 PM, Faré wrote: > OK. Well, I added a test for dll-op, so in the future, this > functionality will hopefully keep working. I didn't add a test for > monolithic-dll-op, though. Sigh. > Thanks, Faré. Your help is very much appreciated. Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://quinfog.iff.csic.es
Re: [asdf-devel] ASDF's MAKE-BUILD breaks ECL's DLL target
On Thu, Jun 27, 2013 at 10:55 PM, Faré wrote:
> I'd like to add a test in test-bundle.script.
> I tried this:
>
> (operate 'dll-op :test-asdf/bundle-2)
> (si:load-foreign-module (first (output-files 'dll-op
> :test-asdf/bundle-2)))
>
> (ffi:def-function "init_dll_BUNDLE_2" () :returning :void)
> (init-dll-BUNDLE-2)
>
> But the function call fails, because it the test script is
> interpreted, not compiled.
> How do I call the initialization function from the interpreter?
>
The initialization function cannot be directly called, so I would rather
recommend the following solution. First, file2.lisp is changed as below.
Then, instead of calling a function, we verify that the library is
available by serching for a symbol
(si::find-foreign-symbol "sample_function" "name-of-dll" :pointer-void 0)
file2.lisp
#+ecl
(ffi:clines "
extern int sample_function();
int sample_function()
{
return 0;
}
")
--
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://quinfog.iff.csic.es
Re: [asdf-devel] ASDF's MAKE-BUILD breaks ECL's DLL target
>> How do I call the initialization function from the interpreter?
>
> The initialization function cannot be directly called, so I would rather
> recommend the following solution. First, file2.lisp is changed as below.
> Then, instead of calling a function, we verify that the library is available
> by serching for a symbol
>
> (si::find-foreign-symbol "sample_function" "name-of-dll" :pointer-void 0)
>
> file2.lisp
> #+ecl
> (ffi:clines "
> extern int sample_function();
>
> int sample_function()
> {
> return 0;
> }
> ")
>
OK. Well, I added a test for dll-op, so in the future, this
functionality will hopefully keep working. I didn't add a test for
monolithic-dll-op, though. Sigh.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
My opinions may have changed, but not the fact that I am right.
Re: [asdf-devel] ASDF's MAKE-BUILD breaks ECL's DLL target
I'd like to add a test in test-bundle.script. I tried this: (operate 'dll-op :test-asdf/bundle-2) (si:load-foreign-module (first (output-files 'dll-op :test-asdf/bundle-2))) (ffi:def-function "init_dll_BUNDLE_2" () :returning :void) (init-dll-BUNDLE-2) But the function call fails, because it the test script is interpreted, not compiled. How do I call the initialization function from the interpreter? —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org It is not recognized in the full amplitude of the word that all freedom is essentially self-liberation — that I can have only so much freedom as I procure for myself by my ownness. — Max Stirner
Re: [asdf-devel] component-load-dependencies
On Thu, Jun 27, 2013 at 3:08 AM, Didier Verna wrote: > Faré wrote: > >> since you provide no justification for what you are trying to do, >> anything can be "reasonable" or not. > > I'm not sure what I need to justify, since my original question was > actually quite precise. > Your original question was quite bogus and shows superficial understanding of the ASDF dependency model. There is no such thing as "component dependencies". The notion doesn't exist in ASDF, never did, and never will. And so, despite any inappropriate naming established by history. Components do NOT have dependencies. Actions do. The dependency graph is a graph of actions, not of components. Components have parents and children, that's all. If you want to know the direct dependencies of an action, use component-depends-on, or map-direct-dependencies or visit-dependencies. If you want to know the indirect dependencies of an action, use make-plan, visit-action, visit-actions, visit-sub-actions, etc. If you want to extract the set of components an action depends on, in dependency order, while dropping the associated operation, use required-components. Anything else is semantically meaningless or incomplete and not directly called by the ASDF planning engine. sideway-dependencies are only a fraction of the user-specified information from which the graph is extracted. But if for some reason you want to put it on a pedestal, then yes, you can resolve it using resolve-dependency-spec, the same way that map-direct-dependencies does. > Thank you very much, but even assuming I don't know what I want and > you know what I want better than I know what I want, I'm still sure > that I don't want the opposite of what I want. > Whatever you're trying to achieve, I hope you're successful at it. >> Have fun playing with ASDF. > > Not really, no. > Then don't do it. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org If Government is the solution to any alleged "failure" of free society, what is the solution to blatant failures of Government?
Re: [asdf-devel] component-load-dependencies
Faré wrote: > since you provide no justification for what you are trying to do, > anything can be "reasonable" or not. I'm not sure what I need to justify, since my original question was actually quite precise. > My bet is that this isn't what you really want in the end, > Usually, one wants to get a list of components within a system. > Then, one typically uses required-components, e.g. like this (YMMV): >> That's the opposite of what I want. Thank you very much, but even assuming I don't know what I want and you know what I want better than I know what I want, I'm still sure that I don't want the opposite of what I want. > Have fun playing with ASDF. Not really, no. -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info
