some projects use .s extension for preprocessed assembly source files, incompatible with zig's extension-based detection #20655
Comments
andrewrk
added
breaking
|
I don't agree that these proposed names are better. C is more than a source file format, it's a particular compilation model ("The C Compilation Model") that involves one file per compilation unit, include directories, the existence of the preprocessor, and "C flags". Let's focus on solving your use case, which is the issue with preprocessed assembly files. Can you explain the problem statement in more detail? |
|
As I can read from #20630, it is planned to long term move support for languages like C more into the build system instead of the compiler. While it goes further than what is needed here, I could see this as basically making it possible for the build system to be a generalized build system (and with it a full blown CMake and Make replacement) if the opportunity is taken to make the chosen language a plugin. (Before somebody asks, I know people who use CMake to build LaTeX documents, Powerpoint presentations (I don't know how either), but also more sane things like Java.) So your package has a dependency on a plugin in the ZON file, you register the plugin in the build system and then you say e.g. via a Sure, this goes quite a lot further than the problem described here, but could tackle quite a few things at once at the downside of it being quite complex (as plugins always are). Also, it would make it possible to have different plugins for different C compilers and maybe even one which tackles C++ modules (TL;DR you can't handle a project which makes use of them internally in a Make like way, you need to dynamically parse them (or use the protocol described in P1689R5 which luckily all major C++ compilers support these days) and then build up a dependency tree). And these plugins can then move independently of each other (besides breaking changes). But as I am entirely an outsider here, these are just my 2cent. |
Yea that makes sense, I was thinking along the lines of "FFI" rather than the "C Compilation Model".
I am trying to compile BlocksDS/libnds with Zig, and the main issue is that assembly files use lowercase I made an issue about this upstream but the developers had a few important points as to why this isn't a great solution in the first place:
|
|
Zig's low-level CLI usage ( |
andrewrk
changed the title
andrewrk
added
use case
|
In general, we need to transition to moving non-zig compilation units into being orchestrated by the build system for a few reasons:
|
That's actually why I brought up my point, especially because of the last point. A surprisingly high amount of system packages does not just have C, C++ and Assembly, but also code in e.g. Fortran (especially in scientific computing) or script files which belong to them (especially games like to do this). |
Yea, I took advantage of that in my fork of Zig (#20687), which (since I updated it today) simply adds a |
…ction. It is normally based on the file extension, but it can be ambiguous. Notably, ".h" is often used for c headers or c++ headers. Or some .s (instead of .S) assembly files still need the c preprocessor. (ziglang#20655)
…ction. It is normally based on the file extension, but it can be ambiguous. Notably, ".h" is often used for c headers or c++ headers. Or some .s (instead of .S) assembly files still need the c preprocessor. (ziglang#20655)
…ction.
It is normally based on the file extension, however:
- it can be ambiguous. for instance,
".h" is often used for c headers or c++ headers.
".s" (instead of ".S") assembly files may still need the c preprocessor. (ziglang#20655)
- a singular file may be interpreted with different languages depending on the context.
in "single-file libraries", the source.h file can be both a c-header to include, or compiled as a C file (with a #define as toggle) (ziglang#19423)
…ction.
It is normally based on the file extension, however:
- it can be ambiguous. for instance,
".h" is often used for c headers or c++ headers.
".s" (instead of ".S") assembly files may still need the c preprocessor. (ziglang#20655)
- a singular file may be interpreted with different languages depending on the context.
in "single-file libraries", the source.h file can be both a c-header to include, or compiled as a C file (with a #define as toggle) (ziglang#19423)
…ction.
It is normally based on the file extension, however:
- it can be ambiguous. for instance,
".h" is often used for c headers or c++ headers.
".s" (instead of ".S") assembly files may still need the c preprocessor. (ziglang#20655)
- a singular file may be interpreted with different languages depending on the context.
in "single-file libraries", the source.h file can be both a c-header to include, or compiled as a C file (with a #define as toggle) (ziglang#19423)
…ction.
It is normally based on the file extension, however:
- it can be ambiguous. for instance,
".h" is often used for c headers or c++ headers.
".s" (instead of ".S") assembly files may still need the c preprocessor. (ziglang#20655)
- a singular file may be interpreted with different languages depending on the context.
in "single-file libraries", the source.h file can be both a c-header to include, or compiled as a C file (with a #define as toggle) (ziglang#19423)
…ction.
It is normally based on the file extension, however:
- it can be ambiguous. for instance,
".h" is often used for c headers or c++ headers.
".s" (instead of ".S") assembly files may still need the c preprocessor. (ziglang#20655)
- a singular file may be interpreted with different languages depending on the context.
in "single-file libraries", the source.h file can be both a c-header to include, or compiled as a C file (with a #define as toggle) (ziglang#19423)
…tection.
and change `addAssemblyFile()` to use a `AsmSourceFile` option struct as well. (breaking change)
Language is inferred from the file extension, however:
- it can be ambiguous. for instance,
".h" is often used for c headers or c++ headers.
".s" (instead of ".S") assembly files may still need the c preprocessor. (ziglang#20655)
- a singular file may be interpreted with different languages depending on the context.
in "single-file libraries", the source.h file can be both a c-header to include, or compiled as a C file (with a #define as toggle) (ziglang#19423)
…tection.
and change `addAssemblyFile()` to use a `AsmSourceFile` option struct as well. (breaking change)
Language is inferred from the file extension, however:
- it can be ambiguous. for instance,
".h" is often used for c headers or c++ headers.
".s" (instead of ".S") assembly files may still need the c preprocessor. (ziglang#20655)
- a singular file may be interpreted with different languages depending on the context.
in "single-file libraries", the source.h file can be both a c-header to include, or compiled as a C file (with a #define as toggle) (ziglang#19423)
Currently, projects with
.S"Assembler with C Preprocessor" files must useaddCSourceFile[s]to add the files to the compilation, while regular.sassembly files can be added with eitheraddAssemblyFileoraddCSourceFile[s], which is a bit confusing.There is also a second problem with the current design;
addCSourceFile[s]has no way of specifying the language of each file, and it is determined by file extension. This means 1. files with non-standard extensions can not be compiled and 2. the only distinction between preprocessed assembly and regular assembly is uppercase/lowercase file extension, which doesn't play well with case-insensitive filesystems and operating systems (example in practice: my project zig-nds has issues with assembler preprocessor).Proposed solution
Replace(not necessary)addAssemblyFileandaddCSourceFile[s]withaddForeignSourceFile[s],Add a
.languagefield in CSourceFile[s] to specify the language of the file[s].The text was updated successfully, but these errors were encountered: