From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp37.i.mail.ru (smtp37.i.mail.ru [94.100.177.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 8ED20469719 for ; Fri, 2 Oct 2020 19:14:19 +0300 (MSK) From: "Timur Safin" References: <96922008cb146eaa04cb727472eda3e71f2e7bc8.1600955781.git.tsafin@tarantool.org> <185c95b5-edc6-10d0-50c0-ba7c086fc97a@tarantool.org> <20200929080304.GV18920@tarantool.org> In-Reply-To: <20200929080304.GV18920@tarantool.org> Date: Fri, 2 Oct 2020 19:14:19 +0300 Message-ID: <0ada01d698d7$15b21030$41163090$@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Content-Language: ru Subject: Re: [Tarantool-patches] [PATCH 2.X 4/7] module api: luaL_register_module & luaL_register_type List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: 'Igor Munkin' , 'Vladislav Shpilevoy' Cc: tarantool-patches@dev.tarantool.org, 'Alexander Turenko' : From: Igor Munkin : Subject: Re: [Tarantool-patches] [PATCH 2.X 4/7] module api: : luaL_register_module & luaL_register_type :=20 : Vlad, :=20 : I glanced the patch and doubt these functions need to be exported by : Tarantool. These functions neither wrap internals nor provide any : performance benefits (e.g. reduce numbers of excess allocations). It : would be nice to have such auxiliary interfaces in so called = "modulekit" : to make third party modules development easier, but I see no problem = to : borrow this code to merger/key_def as is for now. Ok, let me put it another way: - we are agreed that this is necessary useful functionality which might=20 be part of some static library, as part of modulekit? - we are not ok to put those symbols to Tarantool, and use Tarantool=20 executable(s) for linking against those symbols, because it's looking too much intimate. - I'd hardly imagine situation that for such modulekit code reuse we=20 would prefer to introduce yet another repository, compile it as static library and then add to the linking dependencies of an external = module? (or do we?) - as for me it's still looking part of module api (some headers, and = some=20 Helpers in library), and I'd prefer to simply export them from = executable... But.. if we prefer "modulekit" then yes, I'd copy-paste this code to=20 my module and to the GitHub template for Tarantool c modules (yet to be=20 created). Looks redundant, but will save a couple of external symbols. Regards, Timur :=20 : On 29.09.20, Vladislav Shpilevoy wrote: : > Thanks for the patch! : > : > See 2 comments below. : > : > On 24.09.2020 19:00, Timur Safin wrote: : > > Exporting `luaL_register_module` & `luaL_register_type` : > > functions as they needed for external merger : > > : > > diff --git a/src/lua/utils.h b/src/lua/utils.h : > > index 7639cd64a..9b1fe7e57 100644 : > > --- a/src/lua/utils.h : > > +++ b/src/lua/utils.h : > > @@ -78,6 +78,8 @@ luaL_pushuuid(struct lua_State *L); : > > : > > /** \cond public */ : > > : > > +struct luaL_Reg; : > : > 1. It does not seem to be public. How are users supposed to work = with : that? : > Igor, could you please take a look at this? :=20 : It's public[1] and is provided by Lua standard header as : Sasha already mentioned it in the thread. :=20 : > :=20 : :=20 : [1]: https://www.lua.org/manual/5.1/manual.html#luaL_Reg :=20 : -- : Best regards, : IM