Le dimanche 16 novembre 2014 à 15:41 -0500, Erik Schnetter a écrit : > I see. > > I was afraid that the C structs may change in between different > versions of the library. If the structs are re-analyzed when the > wrapper is installed, this would not be an issue. Stable libraries shouldn't change their structs, except when releasing new major versions. In that case even classic C programs will break, so it's not really something to worry about specifically for Julia code. Ideally your package should download a version series known to work, so things don't break even a breaking version is released.
And if a new major version is released and the structs change, other things are likely to change too, so that your code will break anyway. That's what SOVERSION is used for usually. My two cents > On Sun, Nov 16, 2014 at 2:58 PM, Tim Holy <tim.h...@gmail.com> wrote: > > The only person who needs to use Clang.jl is the package developer. Clang > > writes *.jl files that save you the trouble of keyboarding all the julia > > equivalents of the C structs. It also generates the ccall wrappers. You then > > write your package on top of those generated files. Clang is therefore only > > a > > dependency for the developer, not for the user. That said, if you've already > > written all your types, Clang won't provide you with much benefit. > > > > Quite a few packages use Clang, but one I've been involved with is > > CUDArt.jl. > > > > --Tim > > > > > > On Sunday, November 16, 2014 01:01:42 PM Erik Schnetter wrote: > >> Thanks for all the pointers! Things are now working fine without > >> wrapper functions but with 120 lines of immutable type declarations. > >> Clang.jl sounds interesting, but would probably make hwloc.jl too > >> difficult to use if it is a prerequisite. Let's see how often the > >> structs of hwloc change with future versions. > >> > >> hwloc is a portable library that determines the number of cores (and > >> many other properties) of the local machine: see > >> <https://github.com/eschnett/hwloc.jl>. > >> > >> -erik > >> > >> On Sun, Nov 16, 2014 at 12:41 PM, Jake Bolewski <jakebolew...@gmail.com> > > wrote: > >> > No need to flatten if everything is immutable. This file has some > >> > examples > >> > of wrapping structs of structs > >> > https://github.com/jakebolewski/LibGit2.jl/blob/cac78b5c03531b5afbcb0ae042 > >> > 538dd351527752/src/types.jl#L19.> > >> > On Sunday, November 16, 2014 12:33:39 PM UTC-5, Tim Holy wrote: > >> >> AFAIK no need to flatten. > >> >> > >> >> Since Isaiah didn't advertise it himself, I'll mention his Clang.jl > >> >> package, > >> >> which I've found to be a big help in such situations. It's just possible > >> >> you > >> >> may not need any C glue code. > >> >> > >> >> --Tim > >> >> > >> >> On Sunday, November 16, 2014 12:15:50 PM Erik Schnetter wrote: > >> >> > Thanks for the pointers on immutable types. > >> >> > > >> >> > Is it possible to access structs inside structs this way? That a > >> >> > struct inside a struct, not a pointer inside a struct. Is an immutable > >> >> > type again a bits type? Or do I need to flatten the structs to make > >> >> > this work? > >> >> > > >> >> > -erik > >> >> > > >> >> > On Sun, Nov 16, 2014 at 11:16 AM, Isaiah Norton <isaiah...@gmail.com> > >> >> > >> >> wrote: > >> >> > >> The library defines some C structs that are part of the API. My > >> >> > >> current approach uses wrapper C functions to access struct > >> >> > >> elements. > >> >> > >> Is there a better way? > >> >> > > > >> >> > > It depends how complicated are the structs. Structs can often be > >> >> > > reflected > >> >> > > as Julia types, as long as isbits(TypeName) == true, and accessed > >> >> > > with > >> >> > > unsafe_load (see for example PyCall's definitions of PyObject_*). > >> >> > > Some > >> >> > > tricky spots include fixed-size arrays and unions (strictly speaking > >> >> > > you > >> >> > > can make an aggregate element having the maximal size in the union, > >> >> > > and > >> >> > > then do bitshifts manually. but there is no automatic support). > >> >> > > > >> >> > > There is also the StrPack.jl package, which calculates the > >> >> > > appropriate > >> >> > > memory layout for a given struct and provides > >> >> > > serialization/deserialization.> > >> >> > > > >> >> > >> I thus I need to build this wrapper file as well. I created a > >> >> > >> SimpleBuild rule for this. However, I need to know the path where > >> >> > >> BinDeps installed (or found) the header files so that I can compile > >> >> > >> this file. How do I access this information? > >> >> > > > >> >> > > This is going to be package-manager and build-tool specific, and I > >> >> > > don't > >> >> > > know if there is any abstraction/helper for includes in BinDeps yet. > >> >> > > > >> >> > > On Sun, Nov 16, 2014 at 10:09 AM, Erik Schnetter <schn...@gmail.com> > >> >> > > > >> >> > > wrote: > >> >> > >> I want to wrap a library (hwloc) for Julia. This is working fine. > >> >> > >> > >> >> > >> The library defines some C structs that are part of the API. My > >> >> > >> current approach uses wrapper C functions to access struct > >> >> > >> elements. > >> >> > >> Is there a better way? > >> >> > >> > >> >> > >> I thus I need to build this wrapper file as well. I created a > >> >> > >> SimpleBuild rule for this. However, I need to know the path where > >> >> > >> BinDeps installed (or found) the header files so that I can compile > >> >> > >> this file. How do I access this information? > >> >> > >> > >> >> > >> -erik > >> >> > >> > >> >> > >> -- > >> >> > >> Erik Schnetter <schn...@gmail.com> > >> >> > >> http://www.perimeterinstitute.ca/personal/eschnetter/ > > > > >
