Ok. Then scripting is about to load a interpreter for JavaScript and run inside Builder code written in that language, like CPython. Even if you can use LibIED from a script using GObject Introspection, then not Just JavaScript but Python is possible today using PyGObject.
Then, is it possible to load JavaScript interpreter without C++, to avoid change main as .cpp as Michael Catanzaro suggest? I'm really interested in LibIED, its capabilities could be extended to manage any thing different than CODE but any other files types with a VCS, like XML configurations. 2015-02-18 8:12 GMT-06:00 Michael Catanzaro <[email protected]>: > On Tue, Feb 17, 2015 at 7:39 PM, Christian Hergert <[email protected]> > wrote: > > Hi Everyone! Many of you know I've been busy working on LibIDE. It has > come a long way since I started. I finally have a better understanding of > how things are going to work going forward. I'm currently deciding whether > or not we should start pushing this into what will be 3.16. We have a few > weeks left, and to be honest, I think it's more important to get people > testing this than adhering to code freezes. > > > I agree you should not adhere to the code freeze at this stage in the game. > > I am actually going to go one step further and suggest you skip the 3.16 > release entirely, and just go straight to 3.17, targeting 3.18 for your > first stable release. There is value in "release early, release often," but > on the other hand you get one chance to make your first impression, and > releasing too early has backfired for some of our newer apps, like > gnome-music which has been received quite negatively. I don't think it > would be beneficial to Builder for it to show up in distributions before it > can actually build stuff (from the UI, nice to see the ide-build command > now exists!). > > ## Project Files When the `IdeContext` is loaded, the discovered `IdeVcs` > will load all the project files into the project tree. I went back and > forth decided if the BuildSystem or the Vcs should load this content, and I > think the Vcs is the right place to do it. You can test this from the > command line using `./ide-list-files`. > > > Yes, VCS is the right place, because you want to be able to see and edit > files that may not be included in the build system at all, like a HACKING > file or a .doap. (Or God forbid, your project has seven separate build > systems that you need to keep updated....) > > ## IDE Scripting LibIDE gained support for IDE Scripting this week. > Currently, we only have one scripting language engine, which is GJS based. > I bit the bullet and had to write some C++ to host the JS runtime, but was > pleasently surprised how well this works with automake these days. We still > have a C library with C linker yet some code calls into C++ libraries. > Lovely. > > > By including ide-gjs-script.cpp in libide_1_0_la_public_sources, that > causes Autotools to use the C++ linker. Otherwise this would not work. See > from the build output: > > ... > CCLD libeditorconfig.la > CXXLD libide-1.0.la > CCLD libgnome-builder.la > ... > > But yes, including small amounts of C++ in a predominantly C project is > not really any problem nowadays. There is one trick though: you should > write main() in C++ or else C++ static initialization may not take place -> > bugs. To make sure this can never be a problem, just rename main.c to > main.cpp, which will cause Autotools to do the right thing. > > _______________________________________________ > Builder-list mailing list > [email protected] > https://mail.gnome.org/mailman/listinfo/builder-list > > -- Trabajar, la mejor arma para tu superación "de grano en grano, se hace la arena" (R) (en trámite, pero para los cuates: LIBRE)
_______________________________________________ Builder-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/builder-list
