dfintha / barge Goto Github PK

If the NO_COLOR environment variable is set, forward it to pre- and post-build scripts/programs.

The NO_COLOR environment variable's presence indicates that the user does not with to use ANSI terminal color codes to color the output of a terminal application.

The following parts of the community standards are not deployed yet.

• Code of conduct
• Contributing
• Security policy
• Issue templates
• Pull request template

This consists of two parts.

• First, improve the lookup itself, so on non-Linux platforms, the desired binaries are found.
• Second, improve error messages, when said binaries are not found, to make the source of the problem unambiguous.

A short description of the program can always be helpful, and could be used for documentations (see #17).

cargo allows its users to add a build.rs file, which is compiled and run before building. Following the same idea, barge should be able to run a prebuild and postbuild script before and after building the project, respectively.

These files should be written in one of the following languages.

• C (built with clang)
• C++ (built with clang++)
• Python (executed using python or python3)
• Shell script (executed using bash)

This can be done by adding a single field into project configuration files.

The list of project authors should be included in the barge.json file as a separate field (list of strings).

Currently, the dependencies of barge are not documented correctly. This was introduced when toolsets became a matter of choice. This should be fixed in the documentation.

cargo has its own cargo doc subcommand, which generates documentation for a project. barge could utilize a similar concept by using doxygen.

Using barge rebuild without a barge build beforehand causes an error with the message "No such file or directory (os error 2)". This should not happen, rebuild shall act as a build when no build artifacts are present.

Instead of calling a full clean, it should only remove the directories corresponding to the current target.

This is a simple matter of parsing a list of steps instead of a simple step, and using the same utility functions.

This can be easily done by using GitHub actions.

Library projects should result in a single SO file, with the name lib[PROJECT_NAME].so.[VERSION], along with a link pointing to this file, named lib[PROJECT_NAME].so.

• Projects require a new field, defining their type (binary or library).
• Generated internal make recipes require some refinement.
• Issue #3 needs to be completed first, so that a version-based filename can be generated.

The project currently looks like it evolved organically. A simple, robust architecture should be implemented, functionalities separated into layers, and tests added to each layer, and the in between.

This should be done before #36, the multiplatform support can benefit from these refactors.

In its current state, if an error happens, barge stops its execution, and prints the relevant error to the standard error output.
However, these error messages are way too generic.

• Add extra information alongside the original errors in BargeError.
• Extend BargeError with a method to print these in an user-friendly way.

The GNU FORTRAN compiler could be used to compile source files, and linking together the object files does not need any extra workarounds.

A lengthy README is far less informative than a project Wiki, where each functionality's description can have their internals, example use, and arguments specified.

Currently, the following candidates are present.

• Toolset
• Git commit hash (if present)
• Git branch (if present)
• Date/time of compilation
• Date/time of the current build step
• Kind of the build step (pre- or post-)

The WTFPL is a favorite of mine, as it describes complete freedom over the code.

However, it's profane, and a more concise license could be used in its place. The following statements shall be true to the next license of barge.

• Allows free use of the software or its source code.
• States that the author is not responsible for potential bugs and/or misuse.
• Compatible with the licenses of the software's dependencies (mostly MIT and/or Apache 2.0).

An obvious first candidate would be the MIT license (based on the above), however more research is needed to make a choice for the long run.

Currently, the run subcommand does not pass any command-line arguments, which is problematic for software that can only run correctly with such arguments specified.

clang++ -MM $(SOURCES) emits dependecy definitions, which can be used to avoid recompiling everything if any of the header files change. This can improve build times with this tool.

A toolset-specific debugger should be used: gdb or lldb. This also needs the same argument passing mechanism as the run subcommand will get with #31.

According to the GCC online documentation the -MT flag can be used along with -MM to specify the target. The name of the target shall be generated in barge, and the -MT flag shall be used to specify the target instead of mangling the generated names.
Also it is a possible bug that some object files in subfolders are not specified correctly because of this behavior.

It is a rare, but important aspect.

When one is writing an operating system (or othzer low-level code), linker scripts are crucial to reach proper function. It shouldn't be too hard to include support for linker scripts, and it should be done.

The current implementation is a very shoddy,, ad-hoc method, which should be replaced by a more sophisticated one, preferably by using an external crate dedicated to argument parsing.

Currently, barge supports itself being run from the project root folder. If the user uses a terminal editor to edit source files (like vim or emacs) they may attempt to use barge from a project subfolder, which is currently not submitted.

The software could check all of its parent folders to find the barge.json file (similar to git looking for the .git directory).

Argument parsing has its own colorization scheme, which is more convenient to use. Avoid re-coloring it, like other error messages.

There are three build artifact directories in a barge project: bin, doc, and obj. Moving these directories under a build directory would decreate project clutter, and simplify .gitignore files.

The following switches are proposed to barge init.

• --executable: Default, create an executable project.
• --shared-lib: Create a shared library.
• --static-lib: Create a static library.
• --json-only: Use an existing directory and create a barge.json file in it.

Currently, we pay no mind to other platforms than Linux. But there should be support for the Windows, macOS, and *BSD systems, too.

Non-goals: Using MSVC or other compiler suites for Windows!

On Windows, we'd also use GCC or Clang, or the MinGW cross-compiler. This would require MSYS or Cygwin, however, that is not a problem. On macOS, we can only use the LLVM suite, however, it is available after installing the command-line developer tools. Finally, *BSD systems should have little to no difference to Linux systems from our aspect.

Each scenario must be tested, even if only on a virtual machine.

For the Rust programming language, cargo provides a unit testing framework, and has a separate build target for unit test builds. In the same manner, barge should have a similar functionality.

There are two ideas for this.

• Create a new unit testing framework, resembling the Rust unit testing framework.
• Use an existing unit testing framework, and create a build target for it (most viable candidate is gtest).

This should be done by using clang-format.
Each project should have a clang-format configuration, with a default generated on init, which can be edited by the user.

• The barge init subcommand should create a new .clang-format file at the project root.
• The barge format subcommand should be implemented, to run clang-format configured with the above file on the project files.
• After formatting, the changes should not be automatically committed, this is the user's task (just like with cargo fmt).

If make returns with a status other than 0, the previous build artifacts should not be executed.