Corinna Vinschen writes: > If you really want -E to be an exclusive option, then what I'm missing > is the enforcement on the command line.
Yes, this still needs to be implemented, if there is consensus that the idea itself is sound. It may even be possible to process both options correctly, that is reabse with -T, save the database and then process -E, but I didn't want to make it too complicated. > In theory, if you specify the -E option, neither the -T option should > be allowed, nor specifying any additional files on the command line. Well, I'd think files on the command line could be allowed and become ephemeral, even though I don't see what they could be useful for. > The longer I think of it, the more I'm wondering if you really need > the -E option at all. The question is this: Why is it a problem to > add ephemeral DLLs to the DB? I build in stages, so I typically have at least two instances of the build directory present, if something makes trouble I might have more. That means I have several hundred of DLL, if I rebase those the normal way and let them all enter the database, the wiggle room is getting very small very fast. Worse, when I then need to install something else, I must remember to move the build directories away so that these ephemeral DLL are not pushing the newly installed stuff to low adresses (and later generating large holes) and then I need to move everything in place again and do the rebase anew. > And, is the distinction between ephemeral and persistent DLLs not > kind of artificial? But let's keep the distinction for the sake of > discussion. The distinction of the ephemeral DLL is that I _know_ that several sets of them can safely occupy the same base addresses since they will never be in-memory together. > In theory you would want the ephemeral DLLs in the DB, too. After > all, as long as they exist and are in use, they should blend together > with the other, persistent DLLs without colliding with them. As soon > as they disappear from the disk, the next rebase run will remove them > from the DB as well, and another DLL can take the place (if it fits > into the slot). The same happens with the persistent DLLs. If you > remove the package containing cygncurses6.dll, a followup rebase(all) > run will remove the DLL from the DB and it's memory slot is free for > reuse. Yes. If the rebase DB would record "cliques" of DLL and sort them on priority (ID=0 for system and then up and counting, for instance) and whether they are mutually exclusive or not then they could as well go into the DB and stay there, but that is obviously more complicated to implement. I agree that this would be much nicer in concept. > Given that, I don't see a qualitative difference between the DLLs from > the distro and the DLLs you add manually, even if only for testing > purposes. Ultimately they probably need rebasing, they should not > collide with other DLLs, and they are removed from the DB when you > remove them from the disk. Just like the so-called persistent DLLs. I hope I made my reasoning sufficiently clear. The ephemeral DLL as implemented with my patch are just creating two "cliques" of DLL, system and ephemeral. Since ephemeral does not get recorded into the database, most of the (maybe desirable) functionality you outline above is not yet possible, but the things that are immediately useful are already there. The rest can be implemented later (requires new DB format, someone has to do it, yada, yada...). Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds