4 ms·

A package manager for C++ wouldn't be that difficult if there was a sane, uniform build system available. But there is something actively developed in that dir

by boris 10y ago

A package manager for C++ wouldn't be that difficult if there was a sane, uniform build system available. But there is something actively developed in that direction: https://build2.org https://build2.org and https://cppget.org https://cppget.org In fact, the package manager is pretty feature-complete, just the build system is still heavily developed.

gravypod 10y ago
I agree that there is a huge issue with finding a "good" build system for C and C++. There are thinks like Make but they were designed for entierly different mentalities of software then we have now. Things like Eclipse have, in my mind, greatly altered the perception of source organization in modern systems. I don't think many people think of source as a file but as rather a directory/collection of files. I'd love to see a build & package management system for C that would be able to: * Easily configureable by the programmer for a large set of end goals. Whether or not I want to build an executable, use a custom linker, build a specific DLL type of a specific format it needs to be easy. One example I've worked on is getting Make to output just a plain binary for embeded system development or operating system development is a right pain in the ass. I have no clue how to do it. * Build into seperate directories Basically if I want to build a sub project and put it's output into /usr/lib or something then I should easily be able to configure that to happen. Most of the time you want to build into ./build/ or ./bin/ or something like that but don't litter my ./src/ with .obj files. * Build out of the directory structure By default this should look for everything in ./src/ or something to find all of the source files. * Associate source file extensions to compilers. I should be able to associate all of a certian extension to a certian compiler. For example .C->GCC, .S->GAS, .BAS->FBC, etc. A more advanced example may be me needing to compile in a lot of user (being non-programmers in my office) tables. Doing so I could make a .tlb format and a compiler for a .tlb. This .tbl compiler will just internally translate this to a bit of assembly, pass it through GAS, and then give you an object file. This can be linked to the end product and reached from any of the source files. You could also do a .* as a leftover so you can build a library that will pack extra data into the executable that can be unpacked at runtime by your program. This can be done by writing a "compiler" that reads all the data into a flat array and implements a "file system". You could then call a standard API from this compiler the same way that you could read that table. Just a thought. * Documentation AND Examples. I cant tell you how many times I've worked with someone on a project and they've said something along the lines of "do X in make and it'll work better" and it has. There's so many undocumented tricks that it's unreasonable. This is partly because of age, how large the project is, and in my opinion how much cruft the implementation has accumulated.
- MereInterest 10y ago
  I've had good experience with scons. It can make shared/static libraries, executables, etc. If you need a custom linker, that is just changing one variable in the environment. Out-of-source builds take a little bit of configuring, with VariantDir, but work well once they are set up. Scons has a number of "builders", each of which is associated with a file extension. So, for example, I could look for all files in the src directory that end with either ".c" or ".cc", compile the ".c" files as C, compile the ".cc" files as C++, then link them all together with the following command. Program("bin/prog", [Glob('src/*.cc'), Glob('src/*.c')]) Custom builders can be added, so if you want to add any additional association (e.g. ".cu" to compile with CUDA), you can. The documentation (http://scons.org/doc/production/HTML/scons-user/index.html http://scons.org/doc/production/HTML/scons-user/index.html) is pretty good as well

by boris 10y ago

gravypod 10y ago

I agree that there is a huge issue with finding a "good" build system for C and C++. There are thinks like Make but they were designed for entierly different mentalities of software then we have now. Things like Eclipse have, in my mind, greatly altered the perception of source organization in modern systems. I don't think many people think of source as a file but as rather a directory/collection of files. I'd love to see a build & package management system for C that would be able to: * Easily configureable by the programmer for a large set of end goals. Whether or not I want to build an executable, use a custom linker, build a specific DLL type of a specific format it needs to be easy. One example I've worked on is getting Make to output just a plain binary for embeded system development or operating system development is a right pain in the ass. I have no clue how to do it. * Build into seperate directories Basically if I want to build a sub project and put it's output into /usr/lib or something then I should easily be able to configure that to happen. Most of the time you want to build into ./build/ or ./bin/ or something like that but don't litter my ./src/ with .obj files. * Build out of the directory structure By default this should look for everything in ./src/ or something to find all of the source files. * Associate source file extensions to compilers. I should be able to associate all of a certian extension to a certian compiler. For example .C->GCC, .S->GAS, .BAS->FBC, etc. A more advanced example may be me needing to compile in a lot of user (being non-programmers in my office) tables. Doing so I could make a .tlb format and a compiler for a .tlb. This .tbl compiler will just internally translate this to a bit of assembly, pass it through GAS, and then give you an object file. This can be linked to the end product and reached from any of the source files. You could also do a .* as a leftover so you can build a library that will pack extra data into the executable that can be unpacked at runtime by your program. This can be done by writing a "compiler" that reads all the data into a flat array and implements a "file system". You could then call a standard API from this compiler the same way that you could read that table. Just a thought. * Documentation AND Examples. I cant tell you how many times I've worked with someone on a project and they've said something along the lines of "do X in make and it'll work better" and it has. There's so many undocumented tricks that it's unreasonable. This is partly because of age, how large the project is, and in my opinion how much cruft the implementation has accumulated.

MereInterest 10y ago
I've had good experience with scons. It can make shared/static libraries, executables, etc. If you need a custom linker, that is just changing one variable in the environment. Out-of-source builds take a little bit of configuring, with VariantDir, but work well once they are set up. Scons has a number of "builders", each of which is associated with a file extension. So, for example, I could look for all files in the src directory that end with either ".c" or ".cc", compile the ".c" files as C, compile the ".cc" files as C++, then link them all together with the following command. Program("bin/prog", [Glob('src/*.cc'), Glob('src/*.c')]) Custom builders can be added, so if you want to add any additional association (e.g. ".cu" to compile with CUDA), you can. The documentation (http://scons.org/doc/production/HTML/scons-user/index.html http://scons.org/doc/production/HTML/scons-user/index.html) is pretty good as well