On 2019-03-29 14:23, Achim Gratz wrote: > Brian Inglis writes: >>> If you are packaging your own exes and dlls with your own local Cygwin >>> distro, >>> you should point to your local utility directory with a path in a file under >>> /var/lib/rebase/user.d/$USER for each Cygwin userid on each system, or >>> perhaps >>> you might also need to add your own production exes and dlls into >>> /var/cache/rebase/rebase_user and /var/cache/rebase/rebase_user_exe: see >>> /usr/share/doc/Cygwin/_autorebase.README.
>> Achim, thanks for the clarifications; could you please comment on the >> suggested >> approach for handling local production dlls and exes, or explain the best >> approach for migrating from test to prod and handling rebase on target >> systems? > I'm not quite sure what you want to know. As I said before oblivious > rebase was invented for running tests that use freshly built DLL (I > usually package them before running the tests, so the package will have > the un-rebased DLL from before the test was run). For this it suffices > to simply feed in all new DLL names to rebase. If you were to build in > stages and/or combine different builds then you'd somehow have to > remember the DLL from each stage or build, or just collect all the DLL > names again each time you change something. The important thing is that > each oblivious rebase needs to get the list of _all_ DLL that need to > get rebased, since the database only knows about the host system > (i.e. you can't rebase incrementally with --oblivious). I was wondering as my first para above stated, whether rebase_user{,_exe} would be the proper place to add 3rd party Cygwin dlls and exes, that are distributed with Cygwin (internally)? -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised.