You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
RDMD will use the cached executable instead of rebuilding it.
I've made this a separate issue because it's more difficult to solve than issue 6102.
Comments
dlang-bugzilla commented on 2013-03-10T00:15:04Z
(In reply to comment 0)
Modify a static library your program uses.
I assume the library is linked in via pragma(lib, "libname")?
dlang-bugzilla commented on 2013-03-10T00:43:35Z
Ultimately, for this to work correctly all the time, rdmd would need to know where the linker will look for library files. This isn't really realistic as it depends on the linker implementation (e.g. it might consult its own configuration files or environment variables). It's possible to add some heuristics to rdmd, though, e.g. to search /usr/lib, %LIB% / $LIBRARY_PATH, and the current directory.
rdmd --makedepend doesn't mention the dependent libs (libfoo.a)
dmd -deps neither
dmd -v neither
timothee.cour2 commented on 2017-12-07T06:57:58Z
also:
when adding pragma(lib, "foo"); in main.d:
(and s/-Llibfoo.a/-lfoo -L./ to make the build succeed), the dependency on lib foo will appear in both --makedepend, -deps, -v, and the rebuild will happen.
without pragma(lib, "foo"); in main.d:
the dependency is not caught even if command line mentions -Llibfoo.a or -lfoo -L.
Is that desired behavior? requiring pragma(lib) seems less flexible
timothee.cour2 commented on 2017-12-07T08:46:37Z
ok the existing behavior is definitely buggy: when the dependent library is in a directory not equal to ".", a change to that library will not trigger recompilation:
bus_dbugzilla reported this on 2011-08-02T22:32:54Z
Transfered from https://issues.dlang.org/show_bug.cgi?id=6431
CC List
Description
Similar to issue 6102, but for libraries:
RDMD will use the cached executable instead of rebuilding it.
I've made this a separate issue because it's more difficult to solve than issue 6102.
Comments
dlang-bugzilla commented on 2013-03-10T00:15:04Z
(In reply to comment 0)
I assume the library is linked in via pragma(lib, "libname")?
dlang-bugzilla commented on 2013-03-10T00:43:35Z
Ultimately, for this to work correctly all the time, rdmd would need to know where the linker will look for library files. This isn't really realistic as it depends on the linker implementation (e.g. it might consult its own configuration files or environment variables). It's possible to add some heuristics to rdmd, though, e.g. to search /usr/lib, %LIB% / $LIBRARY_PATH, and the current directory.
github-bugzilla commented on 2013-03-10T14:34:31Z
Commit pushed to master at https://github.com/D-Programming-Language/tools
dlang/tools@d7d1785
rdmd: Add some heuristics for detecting updated libraries (issue 6431)
code commented on 2013-03-10T14:54:29Z
I'm marking this as fixed, as a set of heuristics has been implemented in Git master.
If they don't adequately cover your use case, please open another more detailed bug report.
timothee.cour2 commented on 2017-12-07T06:22:26Z
reopening as i just bumped on this issue
rdmd build 20171126
DMD64 D Compiler v2.077.0
build_lib
build_main
edit bar/foo.d
build_lib
build_main => doesn't rebuild
./setup.sh:
rdmd doesn't rebuild if a dependent library changes
build_lib(){
}
build_main(){
rdmd --build-only -of$exe -Llibfoo.a --exclude=bar main.d
$exe
}
./main.d:
import bar.foo;
void main(){ fun(); }
./bar/foo.d:
timothee.cour2 commented on 2017-12-07T06:43:12Z
also:
timothee.cour2 commented on 2017-12-07T06:57:58Z
also:
when adding
pragma(lib, "foo");
in main.d:(and s/-Llibfoo.a/-lfoo -L./ to make the build succeed), the dependency on lib foo will appear in both --makedepend, -deps, -v, and the rebuild will happen.
without
pragma(lib, "foo");
in main.d:the dependency is not caught even if command line mentions -Llibfoo.a or -lfoo -L.
Is that desired behavior? requiring pragma(lib) seems less flexible
timothee.cour2 commented on 2017-12-07T08:46:37Z
ok the existing behavior is definitely buggy: when the dependent library is in a directory not equal to ".", a change to that library will not trigger recompilation:
./bar/foo.d:
The text was updated successfully, but these errors were encountered: