On Thu, 24 May 2018 22:00:31 +0200 Marcel Hollerbach <[email protected]> wrote:
> Hello, > > i took a look at bazel quite a while ago, buck was new to me. > A few more arguements that are better in meson: Both are still new to me. No experience with either. Buck supports more languages, but the syntax and aspects of bazel seem more attractive. > i) both lack the support of native dependencies, there is no direct > easy way for using pkg-config to generate library objects and get the > correct include directories etc. In meson its simply dependency(...) Looks like bazel has missed that for sometime, since at least 2015 or so. I guess it will not be added anytime soon. Seems they may take a different approach with building or fetching those vs assuming present on system. That is a different approach. https://docs.bazel.build/versions/master/external.html#depending-on-other-bazel-projects It does have a deps parameter, not sure on syntax or usage. https://docs.bazel.build/versions/master/bazel-and-cpp.html#build-files > ii) its super easy to get everything in shared objects or static > libraries while keeping the elements that needs to be shared a actual > shared object. I dont see a concept for that in buck nor bazel. > (Usecase, build one libefl.so or libeina.so libecore.so etc. etc.) Not sure I get you there. > iii) meson has c support, the other two dont have that. There seems to be dislike of C and favor of C++ over C these days. I think that is a reflection of both. I know some C or most C can be compiled as C++ or under C++ compiler. Though not wanted in most cases, short of mixing C and C++. Though adding C support from C++ maybe trivial if anything. Since it has C, mostly just switching the compiler, all the rest would pretty much carry over, includes, sources, dependencies, etc. > iiii) take a look how buck handels custom rules. Thats overly complex > without the possibility of using a generate binary that was build in > the same buck config ... Bazel seems better there. > iiiii) bazel does not use make nor ninja, IDEs and editors have > shortcuts for using those files to rebuild a project quite often, i > dont think those editors / IDEs will have support for bazel / buck or > any "new" buildtool that starts to appear. I am not sure when some IDEs will support meson or ninja beyond say EDI. I get your point there. But this came up for Netbeans so if Netbeans switched from ant to building under buck or bazel. That would likely start by adding support for it to the IDE, I would assume. I think they maybe trying to avoid such other generated files. Where meson is like a bridge between old school build systems and new. This maybe more like next generation, not using anything from past. Like if I built something in Gentoo via an ebuild vs using make, cmake, meson etc. Then I would not need to generate a make or ninja file. Since I am making that stuff directly. I think meson is just leveraging the other stuff vs replacing it all entirely. > iiiiii) take a look what buck is build for, this does sound like a > app buildtool / framework, rather than a buildtool that was made for > building a graphic framework Hard to say what all Facebook is using it for, their showcase is all apps. I haven't seen it in use in any of their public repos. I have to check Googles on bazel. > i..i) buck depends on java AND python ... one of the arguments > against meson was that python as a dep is too big, this brings, java > & python! people will love it!! (just kidding) But i really think > that the stream of dependncies is really huge here Looks like they both have some python... I have to agree with you there. I have no clue why mixing such languages. For platform hooks it would make some sense. But not python etc. Unless needed to build such code. To support building python, need some python, is my assumption. Java 87.4% Python 4.1% Shell 3.5% C++ 3.5% Smarty 1.4% HTML 0.1% https://github.com/bazelbuild/bazel Java 88.1% Python 6.5% JavaScript 3.1% C 0.9% Objective-C 0.6% Shell 0.2% Other 0.6% https://github.com/facebook/buck > And at the end, take a look at the syntax. @@ symbols or ":" infront > of something to indicate some meaning-difference, has shown in the > past to not be readable or easily managable. I would prefer to stick > to a DSL that is easy readable and understandable for a project with Pros and cons on syntax. Bazel syntax seems to be better than Buck. One aspect of Meson syntax I have run into a few times is not knowing python. Seems a fair amount there carries over. The syntax of meson is odd at times just the same. But meson and bazel are pretty close. Funny the use of : was mentioned, as its used in meson in place of like an equal sign in bazel. I would think equal to be more readable. Though the use of : for deps could be odd. cc_binary( name = "hello-world", srcs = ["hello-world.cc"], deps = [ ":hello-greet", ], ) executable('entrance', sources : [entrance_srcs, entrance_pam_srcs], include_directories : [inc, pam_inc, top_inc], dependencies : [crypt, deps, ecore_x, pam_dep] ) -- William L. Thomson Jr.
pgpIm56s2AUcX.pgp
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
