[Patch] Rebase: new switch --ephemeral

ASSI Stromeko@nexgo.de
Wed Jun 20 18:19:00 GMT 2012

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

+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:

+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Blofeld:

More information about the Cygwin-apps mailing list