Bug 24127 – ImportC - no way to organize files

Status
NEW
Severity
enhancement
Priority
P1
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2023-09-01T11:20:47Z
Last change time
2024-12-13T19:30:41Z
Keywords
ImportC
Assigned to
No Owner
Creator
Steven Schveighoffer
Moved to GitHub: dmd#20328 →

Attachments

IDFilenameSummaryContent-TypeSize
1889importcbug.tgzTarball of example code to tryapplication/gzip282

Comments

Comment #0 by schveiguy — 2023-09-01T11:20:47Z
Created attachment 1889 Tarball of example code to try When a C file is imported through a path other than the root path, the compiler can use the C file's declarations from a root module (one that is passed on the compile line). However, when the C file is also passed on the command line, the compiler complains that the file can only be imported as a non-packaged file. I have attached an example, reproduced here: ```c foo/bar/cstuff.c void fn() {} ``` ```d foo/bar/dstuff.d module foo.bar.dstuff; import foo.bar.cstuff; void main() { fn(); } ``` When compiling both on the command line: ``` steves@homebuild:~/importcbug$ dmd foo/bar/* foo/bar/dstuff.d(3): Error: module `cstuff` from file foo/bar/cstuff.c must be imported with 'import cstuff;' ``` However, when compiling the C module separately it succeeds: ``` steves@homebuild:~/importcbug$ dmd -c foo/bar/cstuff.c steves@homebuild:~/importcbug$ dmd foo/bar/dstuff.d cstuff.o steves@homebuild:~/importcbug$ ./dstuff ```
Comment #1 by bugzilla — 2023-11-20T04:42:04Z
The exact same thing happens when cstuff.c is actually named cstuff.d. But, when: module foo.bar.cstuff; is added to cstuff.d, it compiles without error. The trouble is, when a module statement is not present, the compiler names the module as if: module <filename>; was present. <filename> is `cstuff`. The compiler does the same thing for .c files - it assigns a module name of `cstuff`, not `foo.bar.cstuff`. This boils down to the fact that C files do not have a means to name the module. I think we're kinda stuck here.
Comment #2 by schveiguy — 2023-11-20T14:09:00Z
(In reply to Walter Bright from comment #1) > This boils down to the fact that C files do not have a means to name the > module. I think we're kinda stuck here. ImportC added import statements to C files, why not module statements?
Comment #3 by git — 2024-02-09T19:20:15Z
I'm experiencing this issue across Dub libraries. I maintain multiple libraries that had used the same name for C modules, e.g. "bindings.c". The compiler complains about module conflicts when an application depends on both libraries. I am forced to workaround this issue by manually namespacing my C modules, e.g. "wgpu_bindings.c".
Comment #4 by trikkuz — 2024-05-23T15:21:21Z
Similar problem here. A C library with different file with the same name: hello/utils.c world/utils.c dmd hello/utils.c world/utils.c won't compile.
Comment #5 by robert.schadek — 2024-12-13T19:30:41Z
THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/dmd/issues/20328 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB