A different approach to building C++ projects
rachelbythebay.com
A different approach to building C++ projects
1–10 of 74 posts
Re: A different approach to building C++ projects
#2One .cc/.h pair, one object
Not always the case; I have a project with
default.o: default.yaml
$(LD) -r -b binary -o default.o default.yaml
extern const char _binary_default_yaml_start[];
extern const char _binary_default_yaml_end[];
#define PARAM_YAML _binary_default_yaml_start
#define PARAM_YAML_LEN (_binary_default_yaml_end - _binary_default_yaml_start)
fwrite(PARAM_YAML, 1, PARAM_YAML_LEN, stdout);
Re: A different approach to building C++ projects
#3This is sort of unrelated, but that reminds me that one of my biggest issues with learning C++ was how I was expected to deal with libraries (particularly on Linux, where conventions will even differ between distros) and building the project. Most guides or what have you sort of teach you how to compile a file or two, but you quickly run into issues that are difficult to solve for a complete beginner without a direct source of feedback.
Re: A different approach to building C++ projects
#4One of the nice things that Visual C++ has is
#pragma comment(lib, "xxx.lib")
I have found myself wishing that GCC would also get something like this.
Re: A different approach to building C++ projects
#5This sounds like it would be fine for code that you write yourself. But if you're only compiling code you wrote then C++ build systems are pretty trivial. The hard bit is dependencies.
Re: A different approach to building C++ projects
#6[deleted]
Re: A different approach to building C++ projects
#7This sounds like it would be fine for code that you write yourself. But if you're only compiling code you wrote then C++ build systems are pretty trivial. The hard bit is dependencies.
One big lesson that newer languages like go and rust seemed to have learned is that the tooling, building and dependency management need to be dictated as part of the language ecosystem. Dealing with tons of other C++ projects written by other people (even in the same company) - how to specify dependencies, where their build artifacts can be found, etc - is a HUGE pain in the ass and consumer of my time.
Re: A different approach to building C++ projects
#8This is sort of the principle of the "bpt" build tool I think from "vector-of-bool"
Re: A different approach to building C++ projects
#9One of the nice things that Visual C++ has is #pragma comment(lib, "xxx.lib") You can specify it in a header file for the library. That way if you include the header file, the library mentioned will automatically get linked as long as it is somewhere in the library search path. I have found myself wishing that GCC would also get something like this.
I wish that would work for all build settings, and be standardized across compilers. Even building complex projects with platform-specific build settings could then be reduced to a simple:
cc main.c -o blaRe: A different approach to building C++ projects
#10One of the nice things that Visual C++ has is #pragma comment(lib, "xxx.lib") You can specify it in a header file for the library. That way if you include the header file, the library mentioned will automatically get linked as long as it is somewhere in the library search path. I have found myself wishing that GCC would also get something like this.
I remember back when I was programming in Delphi I could link directly against a .dll, just take a function prototype from the .h file and translate it into a function declaration like this one:
function I2C_GetNumChannels(out numChannels: Longword): FT_Result; stdcall; external 'libmpsse.dll';