project configuration file about c3c HOT 9 CLOSED

More useful example for this feature:

Should the code have access to used build options during compile time?
Yes. An artificial example (not recommended to be used in practice): depending on optimization for size or speed, during compile time different code path could be selected by compile time if.

Piece of code or a library could, during compile time, check configuration settings and complain if they contain wrong combination, or if there's missing some define. This is, incompletely and clumsily, possible in C via macros.

For example, code may require full optimization on, when it compiles in tests specifically used to guard against performance regressions.

from c3c.

@PavelVozenilek This parallels what's written here in many regards: https://c3lang.github.io/c3docs/project/ can you summarize the differences/improvements you suggest?

from c3c.

https://c3lang.github.io/c3docs/project/

I haven't seen this yet - I am first going through simpler parts of the docs, making notes as it goes.

The basic idea looks quite similar, though I'd avoid un-needed things like authors. I would also remove all dependencies on environment. Use of environment could cause headaches, it is something not clearly visible and fixed in letters. IMHO environment is always misfeature. $HOME is "Unixism", another reason to avoid it.

IMO the configuration should know about:

1. Project root (where the config file sits), known as "." (and using "/" path separator, which is understood on Windows). The ideal project would have everything inside the project tree and no need to care about the rest of filesystem.

2. Where relative path from project root is not feasible, one should use absolute hardcoded paths valid in the current OS. If someone wants to compile the same project on another OS, he should clone the target section a modify these absolute paths. This way mistake/confusion in some target won't affect the rest.

Major differences/improvements:

• In my proposal making new target is something cheap. Copy existing section, make few changes, and that's it. This isolates potential problems. If I screw up completely in one place, the rest should still work.
• I am very strict with contents of configuration file. There should be no freedom to deviate from the expected form. If something could go wrong, it will. Not allowing to go wrong is the solution.
• According to me configuration file would the only way to compile non-trivial (> 1 source file) project. Single source could still use traditional command line options or whatever else.

from c3c.

1. As long as you are anywhere inside of the project structure, the compiler will walk up through the tree to find project.toml. See for details of the mandatory structure: https://c3lang.github.io/c3docs/firstproject/

All paths are relative to that that file, which is placed in the project root. And yes, if platform specific code is needed then another target is created with those settings.

• Adding a target works very much like the copy/paste you suggest.
• The project structure is created from the compiler and is the required form for compiling anything other than single files.

from c3c.

OK. The main (and possibly the only) difference is, that I do not expect the project to have any predefined internal structure.

I hate tools making decisions how project tree should look like. Go language does this - yet another reason for me to avoid that dreck. I have very strong opinions about minimalism, while these tools try to please everyone generating impressive amount of garbage.

from c3c.

Some parts of the structure is necessary to be similar in order to have fewer unnecessary knobs and switches.

from c3c.

About #8 (comment):

I do not see it as necessary. My ideal is (mostly) flat structure, with numerically labeled files and also textual doc files placed inbetween.

Here are parts of generated project tree I do not like (and why):

• build/: the whole build system could be one configuration file. If whole project is built as single source, no intermediate build artifacts are generated.
• lib/: I suppose it is for 3rd party libraries. This arrangement places them away from locations where they would fit best. What is the value of having all foreign libraries in one place? To be able to delete them all at once? lib/ is victory of organization structure (we versus the others) over utility.
• src/: it moves sources form natural place (in the root) one level away. Unnecessary complication.
• tests/: I proposed system of easy tests with no noise, like the need for separate directory.

OTOH, I sometimes find a need to have temp/ directory in project root, for dirty things. E.g. I may want to write down text file with currently running test file name and file, when some unknown test causes crash which cannot be caught with the IDE.

In my opinion any generated project structure should be optional feature, not something forced down one's throat.

from c3c.

Build artifacts are a fact when first transpiling to C. The resulting executable should be placed in a predictable place, not where the compilation was invoked.

But if you want to have everything in a single blob of a director that's possible. Just change the project settings from the defaults. E.g. libs = ["./**"] or libs = ["."] if you don't want recursive inclusion.

from c3c.

Please file this on c3docs.

from c3c.