ngesb has quit [Quit: Connection closed for inactivity]
Zhao has quit [Quit: Connection closed for inactivity]
sanjeev has quit [Remote host closed the connection]
ngesb has joined #soletta
sanjeev has joined #soletta
spoussa has joined #soletta
jeez_ has joined #soletta
casy has joined #soletta
ngesb has quit [Quit: Connection closed for inactivity]
anselmolsm has joined #soletta
otaviobp has joined #soletta
kamidi_preetham has joined #soletta
<gabrielschulhof>
Hey! How imporant is the following scenario in your mind: Somebody types npm install soletta. Soletta is already installed on the system so there's a .pc file which can be used for compiling and linking the bindings.
<gabrielschulhof>
The npm install process reuses the globally available soletta instead of building it from the sources that are part of the npm package.
<gabrielschulhof>
The reason I'm asking is that I'm starting to address the shortcoming whereby the contents of the bindings does not reflect the Soletta configuration settings.
<gabrielschulhof>
That is, if you compile soletta with # OIC is not set, the bindings build process will try to build the OIC bindings, and it will fail, breaking the whole build.
<gabrielschulhof>
If we wish to support the pkgconfig scenario, the bindings build process needs to have a way of detecting the flags with which the global soletta package was built.
<gabrielschulhof>
AFAIK there's no way of detecting that other than to scour the files in the includedir and see which bindings are present.
sanjeev has quit [Remote host closed the connection]
lizardo has joined #soletta
bsmelo has joined #soletta
lvladi has joined #soletta
casy has quit [Ping timeout: 264 seconds]
mbelluzzo has joined #soletta
casy has joined #soletta
spoussa has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
iscaro has joined #soletta
Zhao has joined #soletta
ricardotk has joined #soletta
aguedes has joined #soletta
ceolin[AWAY] is now known as ceolin
glima has joined #soletta
bsmelo_ has joined #soletta
<ceolin>
gabrielschulhof: use the installed version to generate the bindings sounds better, otherwise we can face some problems with different versions between bindings and installed version, although the problem with the features available exists ...
bsmelo has quit [Ping timeout: 250 seconds]
bsmelo_ has quit [Ping timeout: 250 seconds]
<gabrielschulhof>
ceolin: Yeah. That's a bit of a stumbler.
<gabrielschulhof>
ceolin: Can the configuration be added to the .pc file?
<gabrielschulhof>
ceolin: Might make for a large .pc file :)
<ceolin>
gabrielschulhof: have you seen how other projects deal with this ?
<gabrielschulhof>
Not really sure. I've looked at glib, and there doesn't seem to be a config.h or anything.
<gabrielschulhof>
I mean glib as distributed by Fedora.
<ceolin>
gabrielschulhof: we can add a new entry in .pc (available features) but i'm wondering if this is the right approach
<gabrielschulhof>
ceolin: Normally a source package will use detection to determine if certain functions are available in one of its dependencies.
<gabrielschulhof>
ceolin: Like, try to compile a small program.
<gabrielschulhof>
So, I guess having the bindings determine the features is not unprecedented.
<ceolin>
i see
<gabrielschulhof>
... and it's safe to assume that, if sol_oic_client_new() is available, then sol_oic_client_find_resource() is also available.
<ceolin>
sure, but we have to take care if some feature is in some ifdef or not, i've seen it in not exported files, but we need to check in the public ones
<gabrielschulhof>
Yeah. #ifdef statements absolutely need to be avoided in public headers.
<casy>
ceoline
<ceolin>
casy: :)
<casy>
ceolin: sorry for the wrong spelling of ur name
<ceolin>
casy: do not worry
<casy>
ceolin, i'm new to open source.. Is there any soletta documents for newbies
<ceolin>
casy: sure, we have a wiki (with some documents to start). To get a task you can look at our open issues
<ceolin>
we have labeled some of them as easy task for new people
<ceolin>
casy: just a minute and i give to you the links
<gabrielschulhof>
ceolin: I think I will forego the scenario where you run into an already-installed Soletta and instead provide a make install hook so that you always build the bindings and soletta together. If you start with npm install, it will always use a local build, but you can install the bindings globally with make install.
bottazzini has quit [Remote host closed the connection]
<gabrielschulhof>
ceolin: That simplifies the build process by a great deal.
<ceolin>
casy: i recommend you get the source code, build, play with some samples and then get a easy task :)
<gabrielschulhof>
ceolin: After all, if a distribution provides a library and you don't like how it was built, you have to build it from source.
<casy>
ceolin, ok thanks
<gabrielschulhof>
ceolin: So, if a distribution provides soletta and you don't like that it doesn't have node.js bindings, you have to build soletta from source. At that point, you can start with npm install or you can start with make menuconfig && make && make install - up to you, but you have to build from source.
<ceolin>
gabrielschulhof: it simplifies for now indeed
<gabrielschulhof>
Yeah.
<ceolin>
gabrielschulhof: i'll take a look to see how other projects deal with it in meanwhile :)
<gabrielschulhof>
ceolin: Well, the truth is that Soletta is kind of unique in that the node.js bindings are part of the project.
<gabrielschulhof>
ceolin: Normally, you have the C library provided by your distro and a npm package that provides bindings.
<gabrielschulhof>
ceolin: Or, you have a npm package that includes the C library and uses a local copy.
<gabrielschulhof>
ceolin: ... but the npm package and the C library are separate projects.
<ceolin>
i see, but in the first case how the npm is generated ? is the same C source that is installed ?
<ceolin>
npm package
kamidi_preetham has quit [Ping timeout: 250 seconds]
<gabrielschulhof>
ceolin: https://www.npmjs.com/package/ffi is an example of node.js bindings for a C library, where the C library is built locally as part of the npm package.
<gabrielschulhof>
ceolin: The latter assumes the presence of pkg-config and of dev packages for GTK+
<gabrielschulhof>
ceolin: Another point that speaks in favour of not trying to detect a global Soletta is that npm will happily install 15 local copies of a package if 15 other packages independently depend on it. There's absolutely no attempt to reduce duplicate installations.
bsmelo has joined #soletta
<ceolin>
gabrielschulhof: the point is how it checks the gtk features available
<gabrielschulhof>
ceolin: Introspection.
<gabrielschulhof>
ceolin: GObject has that.
<gabrielschulhof>
But that's a GObject-specific thing.
<ceolin>
indeed
bottazzini has joined #soletta
<gabrielschulhof>
It's actually very nice, because GObject has introspection and marshalling, so I'm pretty sure you can even follow along with API changes as GTK+ advances. Not that GTK+ is famous for breaking API :)
bsmelo has quit [Ping timeout: 250 seconds]
bsmelo has joined #soletta
bdilly has joined #soletta
<casy>
ceolin, i just finish building the source code and got the following samples.. coap, common etc . how should i continue?