On Mon, Nov 17, 2014 at 3:15 AM, Milan Bouchet-Valat <[email protected]> wrote: > 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.
In this context, most library users will build from source. I would not expect binary compatibility. So C programs would not break. It is not possible to choose a particular version when installing e.g. via apt-get or homebrew. > 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. I'm not choosing a particular soversion either. I don't think that is even supported with BinDeps? -erik > My two cents > > >> On Sun, Nov 16, 2014 at 2:58 PM, Tim Holy <[email protected]> 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 <[email protected]> >> > 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 <[email protected]> >> >> >> >> >> >> 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 >> >> >> > > <[email protected]> >> >> >> > > >> >> >> > > 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 <[email protected]> >> >> >> > >> http://www.perimeterinstitute.ca/personal/eschnetter/ >> > >> >> >> > -- Erik Schnetter <[email protected]> http://www.perimeterinstitute.ca/personal/eschnetter/
