Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RDMD] Modifying a library doesn't trigger a rebuild #107

Open
mdparker opened this issue Jun 21, 2023 · 0 comments
Open

[RDMD] Modifying a library doesn't trigger a rebuild #107

mdparker opened this issue Jun 21, 2023 · 0 comments

Comments

@mdparker
Copy link
Member

bus_dbugzilla reported this on 2011-08-02T22:32:54Z

Transfered from https://issues.dlang.org/show_bug.cgi?id=6431

CC List

  • code
  • dlang-bugzilla
  • razvan.nitu1305
  • timothee.cour2

Description

Similar to issue 6102, but for libraries:

  1. Build some program with RDMD
  2. Modify a static library your program uses.
  3. Run RDMD again.

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)

  1. 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.

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:

module bar.foo;
import std.stdio;
void fun(){writeln("ok4");}

timothee.cour2 commented on 2017-12-07T06:43:12Z

also:

  • 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:

./setup.sh:

## buggy behavior (correct behavior only with build_dir=.)
build_dir=temp

build_lib(){
        dmd -of=$build_dir/libfoo.a -lib bar/foo.d
}

build_main(){
        rdmd -v --build-only -of$exe -L-lfoo -L-L$build_dir --exclude=bar main.d
        $exe
}

build_all(){
        build_main
        touch $build_dir/libfoo.a
        build_main
}


./main.d:
```dlang
pragma(msg, "compiling...");
import bar.foo;
pragma(lib, "foo");
void main(){ fun(); }

./bar/foo.d:

module bar.foo;
void fun(){
        import std.stdio;
        writeln("ok1");
}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant