Re: Is this rdmd bug or my fault ?
Can anybody explain: Is dependencies file produced from command: dmd -deps=moduleA.deps moduleA.d must contains mention of moduleC? Is dependencies file produced reccursively? Thanks.
Re: Is this rdmd bug or my fault ?
On Friday, 8 January 2016 at 22:36:49 UTC, Tobi G. wrote: On Saturday, 9 January 2016 at 01:43:57 UTC, Ivan Kazmenko wrote: I get also a compilation error (with rdmd and -g). Thanks Tobi and Ivan. https://issues.dlang.org/show_bug.cgi?id=15533
Re: Is this rdmd bug or my fault ?
On Friday, 8 January 2016 at 15:45:52 UTC, zabruk70 wrote: Should i create bugreport, or this is my mistake? Same here: rdmd moduleA.d works. rdmd -g moduleA.d produces a linker error. What's more: rdmd -m64 -g moduleA.d fails, and rdmd -m64 moduleA.d also fails. I have dmd 2.069.2 here. Older versions seem to behave the same. Please file a report at issues.dlang.org.
Re: Is this rdmd bug or my fault ?
On Friday, 8 January 2016 at 15:45:52 UTC, zabruk70 wrote: Should i create bugreport, or this is my mistake? I get also a compilation error (with rdmd and -g). Fortunately building manually with dmd works. So there has to be a bug in rdmd.. togrue
Is this rdmd bug or my fault ?
OS: Windows 7 (32 bit) dmd: 2.069.2 and 2.070.0-b1 Then i used "-g" switch with RDMD, then i have OPTLINK error. Reduced code, 3 modules, 2 of them in subdir: moduleA.d test\moduleB.d test\moduleC.d / module moduleA; public void funcA () { import test.moduleB: funcB; return; } void main(string[] args) { return; } / module test.moduleB; public void funcB () { import test.moduleC: funcC; funcC(); return; } / module test.moduleC; public void funcC () { return; } / C:\dmd2\windows\bin\rdmd.exe moduleA.d //no errors, moduleA.exe created C:\dmd2\windows\bin\rdmd.exe -g moduleA.d Copyright (C) Digital Mars 1989-2013 All rights reserved. http://www.digitalmars.com/ctg/optlink.html C:\Users\user\AppData\Local\Temp\.rdmd\rdmd-moduleA.d-D3D7676836384146D1D9D907CF20EC26\objs\moduleA.exe.obj(moduleA.exe) Error 42: Symbol Undefined _D4test7moduleC5funcCFZv --- errorlevel 1 Problem disappear, then i move import in test.modileB to global level: / module test.moduleB; import test.moduleC: funcC; //this works public void funcB () { //import test.moduleC: funcC; //this dont works funcC(); return; } / Should i create bugreport, or this is my mistake?
Re: Is this RDMD bug ?
On Saturday, 23 August 2014 at 18:55:08 UTC, Marc Schütz wrote: But imported modules are the important case. If I have an important bugfix in a module, and don't want to wait for the next release, what am I supposed to do? Rebuild Phobos. If rdmd were to compile your module, linking would fail due to duplicate symbols. I don't know how rdmd works exactly, but AFAICS `dmd -deps` already outputs the full paths of the imported files, recursively. Isn't that enough? rdmd also needs to know which directory contains Phobos sources.
Re: Is this RDMD bug ?
On Saturday, 23 August 2014 at 18:28:32 UTC, Vladimir Panteleev wrote: On Saturday, 23 August 2014 at 18:23:25 UTC, sigod wrote: Isn't it better to document such things? Yes. Please create a pull request. Easy to say. In my TODO list lies record to create PR for [this issue][0]. Today is exactly 2 months as it was created. [0]: https://issues.dlang.org/show_bug.cgi?id=12986
Re: Is this RDMD bug ?
On Saturday, 23 August 2014 at 18:43:35 UTC, Vladimir Panteleev wrote: On Saturday, 23 August 2014 at 18:41:58 UTC, Marc Schütz wrote: On Saturday, 23 August 2014 at 17:41:38 UTC, Dicebot wrote: On Saturday, 23 August 2014 at 17:37:39 UTC, sigod wrote: On Saturday, 23 August 2014 at 17:32:15 UTC, Vladimir Panteleev wrote: No, it is not an rdmd bug. "etc" is a standard D package name reserved for Phobos, the standard library. It is the same for "std" and "core". Please, point us directly to a documentation where it says that this words reserved. http://dlang.org/phobos/ ? (you don't expect to casually use package names "std" and "core" either, do you?) Why not? If I want to amend the standard library, e.g. for testing a module that's not yet present in my compiler version, or for fixing an error? I think it's useful to be able to override individual modules by placing a copy of them into your project's directory. For the record, rdmd handles this particular case just fine. You can run unit tests on any one Phobos module with "rdmd -main -unittest module.d". The package exclusion list only applies to imported modules. But imported modules are the important case. If I have an important bugfix in a module, and don't want to wait for the next release, what am I supposed to do? I don't know how rdmd works exactly, but AFAICS `dmd -deps` already outputs the full paths of the imported files, recursively. Isn't that enough?
Re: Is this RDMD bug ?
On Saturday, 23 August 2014 at 18:41:58 UTC, Marc Schütz wrote: On Saturday, 23 August 2014 at 17:41:38 UTC, Dicebot wrote: On Saturday, 23 August 2014 at 17:37:39 UTC, sigod wrote: On Saturday, 23 August 2014 at 17:32:15 UTC, Vladimir Panteleev wrote: No, it is not an rdmd bug. "etc" is a standard D package name reserved for Phobos, the standard library. It is the same for "std" and "core". Please, point us directly to a documentation where it says that this words reserved. http://dlang.org/phobos/ ? (you don't expect to casually use package names "std" and "core" either, do you?) Why not? If I want to amend the standard library, e.g. for testing a module that's not yet present in my compiler version, or for fixing an error? I think it's useful to be able to override individual modules by placing a copy of them into your project's directory. For the record, rdmd handles this particular case just fine. You can run unit tests on any one Phobos module with "rdmd -main -unittest module.d". The package exclusion list only applies to imported modules.
Re: Is this RDMD bug ?
On Saturday, 23 August 2014 at 17:41:38 UTC, Dicebot wrote: On Saturday, 23 August 2014 at 17:37:39 UTC, sigod wrote: On Saturday, 23 August 2014 at 17:32:15 UTC, Vladimir Panteleev wrote: No, it is not an rdmd bug. "etc" is a standard D package name reserved for Phobos, the standard library. It is the same for "std" and "core". Please, point us directly to a documentation where it says that this words reserved. http://dlang.org/phobos/ ? (you don't expect to casually use package names "std" and "core" either, do you?) Why not? If I want to amend the standard library, e.g. for testing a module that's not yet present in my compiler version, or for fixing an error? I think it's useful to be able to override individual modules by placing a copy of them into your project's directory.
Re: Is this RDMD bug ?
On Saturday, 23 August 2014 at 18:12:44 UTC, novice2 wrote: On Saturday, 23 August 2014 at 17:32:15 UTC, Vladimir Panteleev wrote: "etc" is a standard D package name reserved for Phobos, the Thanks for explanation. I not be able to undertsand the cause - weird error message. Now i can easy fix my code. BTW, did rdmd determine user code or standard library by sorce file pathes? Or it those names must be hardcoded? The top-level package names (std, etc and core) are currently hard-coded in rdmd.
Re: Is this RDMD bug ?
On Saturday, 23 August 2014 at 18:23:25 UTC, sigod wrote: Isn't it better to document such things? Yes. Please create a pull request.
Re: Is this RDMD bug ?
On Saturday, 23 August 2014 at 18:23:25 UTC, sigod wrote: Actually, I never got to use this names for first package name. (I only used `.etc` and `.core`.) So, I didn't thought about this. `.etc` and `.core` should work fine. Only the three top-level package names are reserved by rdmd for Phobos/Druntime.
Re: Is this RDMD bug ?
On Saturday, 23 August 2014 at 17:41:38 UTC, Dicebot wrote: On Saturday, 23 August 2014 at 17:37:39 UTC, sigod wrote: On Saturday, 23 August 2014 at 17:32:15 UTC, Vladimir Panteleev wrote: No, it is not an rdmd bug. "etc" is a standard D package name reserved for Phobos, the standard library. It is the same for "std" and "core". Please, point us directly to a documentation where it says that this words reserved. http://dlang.org/phobos/ ? (you don't expect to casually use package names "std" and "core" either, do you?) Actually, I never got to use this names for first package name. (I only used `.etc` and `.core`.) So, I didn't thought about this. But, if to think about it know: `std` - no. `core` - yes. `etc` - yes. It isn't documented. So, why should I think that this is reserved package names? Actually, I myself never thought that there's exist such thing as "reserved package name". Isn't it better to document such things? Less questions will arouse. Less users will stumble on strange errors.
Re: Is this RDMD bug ?
On Saturday, 23 August 2014 at 17:32:15 UTC, Vladimir Panteleev wrote: "etc" is a standard D package name reserved for Phobos, the Thanks for explanation. I not be able to undertsand the cause - weird error message. Now i can easy fix my code. BTW, did rdmd determine user code or standard library by sorce file pathes? Or it those names must be hardcoded?
Re: Is this RDMD bug ?
On Saturday, 23 August 2014 at 17:37:39 UTC, sigod wrote: On Saturday, 23 August 2014 at 17:32:15 UTC, Vladimir Panteleev wrote: No, it is not an rdmd bug. "etc" is a standard D package name reserved for Phobos, the standard library. It is the same for "std" and "core". Please, point us directly to a documentation where it says that this words reserved. I don't think this limitation is documented anywhere currently. The problem is that rdmd needs a way to know which modules will be present in phobos.lib to avoid compiling and linking them twice. Currently, it considers that "std", "etc" and "core" are package names used by the standard library, not user code. The alternative would be to e.g. make rdmd contain the exact list of modules in Phobos (which is unmaintainable, and would still result in similar errors when the full module name clashes), or make rdmd check the filesystem location of each imported module (which is not trivial and may require additional configuration on non-standard D installations, thus breaking any existing ones).
Re: Is this RDMD bug ?
On Saturday, 23 August 2014 at 17:37:39 UTC, sigod wrote: On Saturday, 23 August 2014 at 17:32:15 UTC, Vladimir Panteleev wrote: No, it is not an rdmd bug. "etc" is a standard D package name reserved for Phobos, the standard library. It is the same for "std" and "core". Please, point us directly to a documentation where it says that this words reserved. http://dlang.org/phobos/ ? (you don't expect to casually use package names "std" and "core" either, do you?)
Re: Is this RDMD bug ?
On Saturday, 23 August 2014 at 17:32:15 UTC, Vladimir Panteleev wrote: No, it is not an rdmd bug. "etc" is a standard D package name reserved for Phobos, the standard library. It is the same for "std" and "core". Please, point us directly to a documentation where it says that this words reserved.
Re: Is this RDMD bug ?
On Saturday, 23 August 2014 at 17:29:15 UTC, sigod wrote: PR that introduced regression: https://github.com/D-Programming-Language/tools/pull/108 Filed: https://issues.dlang.org/show_bug.cgi?id=13366
Re: Is this RDMD bug ?
On Saturday, 23 August 2014 at 16:28:46 UTC, novice2 wrote: I have 2 reduced files, wich i can't compile with new (DMD 2.066) rdmd.exe under Windows 7 32-bit. Command: rdmd --force --build-only aaa.d Message "Error 42: Symbol Undefined _D3etc3bbb3fooFZi" But command: dmd aaa.d etc\bbb.d Compile without errors. And then i replace rdmd.exe by old (from DMD 2.065) compile OK too. No, it is not an rdmd bug. "etc" is a standard D package name reserved for Phobos, the standard library. It is the same for "std" and "core". I was the one who introduced the change[1] which unfortunately broke your code. However, the change fixed using rdmd to compile programs which imported std.net.curl or etc.c.curl. [1]: https://github.com/D-Programming-Language/tools/pull/108
Re: Is this RDMD bug ?
On Saturday, 23 August 2014 at 16:28:46 UTC, novice2 wrote: I have 2 reduced files, wich i can't compile with new (DMD 2.066) rdmd.exe under Windows 7 32-bit. Command: rdmd --force --build-only aaa.d Message "Error 42: Symbol Undefined _D3etc3bbb3fooFZi" But command: dmd aaa.d etc\bbb.d Compile without errors. And then i replace rdmd.exe by old (from DMD 2.065) compile OK too. Can anybody reproduce this? /*** begin of file aaa.d ***/ import etc.bbb; void main() { int i = foo(); } /***/ /*** begin of file etc\bbb.d ***/ module etc.bbb; public int foo() { return 1; } /***/ Confirmed. If you change the module name everything works. i.e. change `etc` to something else.
Re: Is this RDMD bug ?
PR that introduced regression: https://github.com/D-Programming-Language/tools/pull/108
Re: Is this RDMD bug ?
On Saturday, 23 August 2014 at 16:28:46 UTC, novice2 wrote: I have 2 reduced files, wich i can't compile with new (DMD 2.066) rdmd.exe under Windows 7 32-bit. Command: rdmd --force --build-only aaa.d Message "Error 42: Symbol Undefined _D3etc3bbb3fooFZi" But command: dmd aaa.d etc\bbb.d Compile without errors. And then i replace rdmd.exe by old (from DMD 2.065) compile OK too. Can anybody reproduce this? Yes. Looks like regression.
Is this RDMD bug ?
I have 2 reduced files, wich i can't compile with new (DMD 2.066) rdmd.exe under Windows 7 32-bit. Command: rdmd --force --build-only aaa.d Message "Error 42: Symbol Undefined _D3etc3bbb3fooFZi" But command: dmd aaa.d etc\bbb.d Compile without errors. And then i replace rdmd.exe by old (from DMD 2.065) compile OK too. Can anybody reproduce this? /*** begin of file aaa.d ***/ import etc.bbb; void main() { int i = foo(); } /***/ /*** begin of file etc\bbb.d ***/ module etc.bbb; public int foo() { return 1; } /***/