Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Xmake, a modern C/C++ build utility

github.com

Post reply on HN
Print view View original

101–110 of 190 posts

Re: Show HN: Xmake, a modern C/C++ build utility

#101

Post by soapdog »

waruqi wrote: post #90
soapdog wrote: post #82

a developer post a well rounded tool with documentation that was built with a lot of care. The comment thread is mostly about other tools or people dismissing the work done because another available offer is more popular or common. When did "Show HN" threads became shark tank? Can people at least check and post about the tool itself instead of discussing CMake vs Ninja vs Meson?

Yes, I agree very much.

I really want to use your tool in a future project. I know Lua well enough and being encumbered at work with a legacy project that requires a crazy build pipeline that uses gyp and friends, makes me eager to try some other stuff.

Thanks for trying to improve the ecosystem around native code building tools. I appreciate it a lot.

Re: Show HN: Xmake, a modern C/C++ build utility

#102

Post by yoz-y »

RcouF1uZ4gsC wrote: post #5

For better or worse though, CMake has won! Many IDE's including Visual Studio can directly work with CMake files. In addition, even Google which is famous for doing things their own way, has now added official, first-class CMake support to their open source C++ library Abseil https://abseil.io/blog/20190402-cmake-support If you are writing an open source C++ library, even if you support some other C++ build system, c…

I quite like CMake, I find it to be the least bad of the bunch. With recent additions I'd say that the only problem is that many packages still need to pull a CMake module from somewhere to be found because they do not offer pkg-config files.

Re: Show HN: Xmake, a modern C/C++ build utility

#103

Post by stkdump »

flohofwoe wrote: post #97
claudius wrote: post #77

What I miss about these tools is some "relatively" straightforward dependency detection and generation. That is, I have a bunch of .cpp files which need to be compiled into individual executables in a folder bin/. I also have a folder inc/ which contains some headers (.h) and those headers possibly also have some associated TU (.cpp). Now g++ can already generate a dependency graph of headers for an executable. It is…

How would a tool know from a header dependency, in which source file the implementation for the header lives? C or C++ don't require any relationship between a declaration file and implementation file. The implementation could be in an entirely differently named source file, or spread over various files, mixed with implementation code from other headers, or included right in the header.

In the common 2 step generation model of C and C++, this information is not needed. When generating object files it is not relevant which .c/.cpp file corresponds to which header files, because they are no inputs to that. Linkong has to happen when any object file changed.

Re: Show HN: Xmake, a modern C/C++ build utility

#104

Post by enriquto »

geezerjay wrote: post #80
flukus wrote: post #15

Earlier quoted context omitted.

I think half those N's are cmake itself considering the amount of time I see "requires cmake x.x or above" messages. I wouldn't find having many build system such an issue if they'd just add a makefile (and maybe ./configure) to call that build system, giving devs a consistent interface and not having to lookup up how to do a simple build.

> if they'd just add a makefile (and maybe ./configure) That's the whole point of cmake. Instead of running autotool's ./configure (which in fact is a whole dance involving autoconf, autoreconf, automake, and whatnot) just run cmake . to get yourself a fancy makefile.

if cmake was any good, the makefiles it produces would be portable, and distributing the cmake program itself would be unnecessary

Re: Show HN: Xmake, a modern C/C++ build utility

#105

Post by adrian_b »

flohofwoe wrote: post #97
claudius wrote: post #77

What I miss about these tools is some "relatively" straightforward dependency detection and generation. That is, I have a bunch of .cpp files which need to be compiled into individual executables in a folder bin/. I also have a folder inc/ which contains some headers (.h) and those headers possibly also have some associated TU (.cpp). Now g++ can already generate a dependency graph of headers for an executable. It is…

How would a tool know from a header dependency, in which source file the implementation for the header lives? C or C++ don't require any relationship between a declaration file and implementation file. The implementation could be in an entirely differently named source file, or spread over various files, mixed with implementation code from other headers, or included right in the header.

Generating automatically the dependencies is trivial with gcc and GNU make, if you just take care to group adequately in directories and subdirectories.

I.e. you just have to put all the source files from which you generate object files that will go in the same libray in a set of directories which does not contain files that will not go there.

Similarly, all the source files for the object files required for an executable, except those that are in libraries, should be in a set of directories.

The sets of directories need not be disjoint, just a given set must not contain files that must be excluded for linking a certain target, as that will make the building process more complex.

Given this constraints, it is possible to write a universal GNU makefile usable for any project, which will generate automatically all dependencies.

For any executable or library you want to build, it is enough to write an extremely small makefile, containing 4 lists (of defined symbols, of source files, of directories with header files and of libraries) and the name of the generated file and its type (excutable, shared library, static library).

At the end you need to include a makefile that is good for any project targetting a certain CPU + operating system combination.

The makefiles per CPU/OS must define a few things, e.g. the compiler used and other utilities, option flags for all, locations of the tools and so on, then you include a unique makefile for all architectures and operating systems.

I have started using this method more than twenty years ago and I have never ever needed to write manually any dependency information.

Whenever I see the huge and intricate and impossible to maintain makefiles that are too frequently encountered in many software projects, I wonder how one is willing to waste so much time with a non-essential part of the project.

From my point of view, building easily any large software project is a problem solved a long time ago by gcc & GNU make, but for reasons that I cannot understand most people choose to not do it in the right way.

Of course having to use in 2019 a programming language which does not implement modules by any better method than including header files is something even more difficult to understand, but I still must use C/C++ in my work, as there is no alternative for most embedded computers.

Re: Show HN: Xmake, a modern C/C++ build utility

#106

Post by waruqi »

soapdog wrote: post #101
waruqi wrote: post #90

Earlier quoted context omitted.

Yes, I agree very much.

I really want to use your tool in a future project. I know Lua well enough and being encumbered at work with a legacy project that requires a crazy build pipeline that uses gyp and friends, makes me eager to try some other stuff. Thanks for trying to improve the ecosystem around native code building tools. I appreciate it a lot.

Thank you very much for your support.

Re: Show HN: Xmake, a modern C/C++ build utility

#107

Post by roel_v »

geezerjay wrote: post #86
rusk wrote: post #73

Earlier quoted context omitted.

> just create a virtual environment Yaw super lightweight ...

Actually it is, but nevertheless that's only required by those who for some reason still believe today that python2 vs python3 is an issue.

I have python 2 vs 3 issues if not every day, then at least 3 times a week, because of being stuck with a version of third party software that uses Python 2 (ArcGIS 10 series) for part of my code base. Of course Python apologists are now going to say 'oh you're just one guy in a niche situation', and 'yeah that's what you get for not upgrading to the latest version of all software', or any of the dozens of other excuses and blame I get anytime I have to defend why I need to use Python 2. Fact is still that I'm bound by external constraints and that Python versioning is a real problem in my day to day work, and yes that is in 2019. Look, Python isn't much worse or better than most other languages in its niche, but please do away with the 'everything about Python is easy and great' spiel.

Re: Show HN: Xmake, a modern C/C++ build utility

#108

Post by adrian_b »

adrian_b wrote: post #105
flohofwoe wrote: post #97

Earlier quoted context omitted.

How would a tool know from a header dependency, in which source file the implementation for the header lives? C or C++ don't require any relationship between a declaration file and implementation file. The implementation could be in an entirely differently named source file, or spread over various files, mixed with implementation code from other headers, or included right in the header.

Generating automatically the dependencies is trivial with gcc and GNU make, if you just take care to group adequately in directories and subdirectories. I.e. you just have to put all the source files from which you generate object files that will go in the same libray in a set of directories which does not contain files that will not go there. Similarly, all the source files for the object files required for an execu…

Sorry, there are several typos in my message above. For most of them it is obvious which was the correct intended word.

However, one typo can lead to a confusion because an entire word is missing. In the 4 lists that must be written in the makefile, the most important list, as the other lists can be omitted, is the list of directories with source files (not a list of source files).

For simple projects the list will be reduced to a single source directory. Whenever you add, delete or rename source files, there is no need to edit the makefile of the project.

All changes can be taken automatically into account by GNU make, which can be instructed to scan the source directories for source files for all the programming languages that you use.

Re: Show HN: Xmake, a modern C/C++ build utility

#109

Post by sandGorgon »

2bluesc wrote: post #14

Meson[0] has been gaining in popularity and has migration tools for cmake projects. Large projects such as systemd and gnome[1] have migrated or have been migrating for years [0] https://mesonbuild.com/ [1] https://wiki.gnome.org/Initiatives/GnomeGoals/MesonPorting

what about Bazel ? https://bazel.build/

Re: Show HN: Xmake, a modern C/C++ build utility

#110

Post by rusk »

geezerjay wrote: post #86
rusk wrote: post #73

Earlier quoted context omitted.

> just create a virtual environment Yaw super lightweight ...

Actually it is, but nevertheless that's only required by those who for some reason still believe today that python2 vs python3 is an issue.

There are a few different meanings of the word lightweight, and I get a sense you're not using the one that I or GP are using.
Post reply on HN