Mail Archives: cygwin-apps/2002/02/26/16:22:08
On Tue, Feb 26, 2002 at 09:54:37AM +1100, Robert Collins wrote:
> ----- Original Message -----
> From: "Jason Tishler" <jason AT tishler DOT net>
> > I guess that I was trying to ask a more philosophical question of how
> > coupled rebase was going to be with setup.exe. It sounds like you are
> > comfortable with a tight coupling. Is this correct?
> Yes. I think that setup.exe based rebasing should be optional, but
> default to on. A flag in rebase.conf to control this would be good,
> along with a dialogue box and a tick :]. Not needed for the initial
> merge though.
OK, sounds good. I'm not a GUI guy -- I hope that Gary will come to my
> > I haven't tried LoadLibrary(), etc. but I presume that one of the
> > APIs can. However, isn't this too little, too late? What can we do
> > when the corruption occurs? Rollback to the copy in the archive?
> > But, then this image will *not* be rebased. :,(
> I was thinking of the following process (for all dlls we attempt to
> 0) Check that it hasn't been rebased already.
What is the purpose of the above? I already rebase DLLs into their
previous space during reinstalls, if they still fit.
> 1) Copy
> 2) Rebase
> 3) Check for corruption - mark as occupying it's own prior space if
> corrupt and then stop, otherwise mark it's new space in the used list.
What happens when the prior space is already taken?
> We can yes, it's certainly not urgent. My concept rough concept on the
> process was that rebasing would be moved out of the install routines
> (because uninstalls free up used list space) and be made to occur after
> all the files have been installed, we'd have a complete list of .dll's
> that need may rebasing, and whose dependents should be checked at the
> same time.
Is the "complete list" approach above required for the first iteration?
> (Or do you rebase cygwin1.dll as well :]]).
Yes, I can rebase cygwin1.dll too. This is why I converted the
stand-alone rebase to a Mingw app.
> > > 1) log.cc - don't clean up there. If you need to cleanup, have a
> > > static object whose destructor should get called.
> > This is already done too (see rebaser.cc:338). Note that my
> > stand-alone rebase.exe is already using this successfully.
> Gotcha, ok the log.cc call should go then - or does this introduce sife
Currently, the config file won't be saved. This won't be a problem once
the config file is saved as soon as the installation phase is finished.
> > > 2) I really don't like the rebaser::set_cygwin_root_dir construct:
> > > why not use get_root_dir () when you need the cygwin root? (Any
> > > why do you need it? Surely you only need cygpath (filename) ?
> > This is for the stand-alone case which I wasn't sure was going to be
> > able to easily share code with setup.exe. This concern appears to
> > be mitigated. I can certainly have rebaser always retrieve the Cygwin
> > root from the registry if this is deemed the better approach.
> Ah. Well within setup io_stream is the answer as they
Huh? You didn't finish the above sentence.
> > I tried to find the appropriate abstractions in the problem domain.
> > I tried to encapsulate implementations behind reasonable interfaces to
> > minimize the impact of implementations changes. Etc, etc. However,
> > I'm open to design changes too, if deemed necessary.
> What feels procedural is separate classes for serialisation. I _feel_
> (And can there for be told to get my nose out of it) that a better
> encapsulation would be for the used list and free list to have
> [de]serialisation capability, and the config_file class to shrink to
> simply finding the config file, identifying the beginning of (say) a
> used list section, and then passing the buck. Would you care to comment
> on this as opposed to your current model?
Ah, I see your point. I guess that it depends on how you want to slice
and dice. I have used the load/save paradigm many times before and in
general prefer it. However, in this case I don't quite think of the
config file data as object state. What happens if there are syntax
errors, etc.? I think that a config file object should deal with these
kinds of issues (although is could delegate some of the responsibility to
the list objects). Additionally, with my current approach I can change
the config file format without affecting the list classes.
Nevertheless, if you feel strongly, then I will change my perspective.
> > > 9) Should we rename my 'list.h' to 'vector.h'
> > vector does seem to better capture the semantics. But, what is the
> > relevance to my list code? Are you suggesting that I use your stuff.
> > I tried but I needed STL map-like functionality.
> I'm suggesting I get my stuff out of your way :}. Your code seems
> traditional list based, which mine isn't (anymore), so your code could
> generalise to be a list/map template.
OK, sounds good.
> > > 10) Please capitalise the first letter of words in class names.
> > > Setup has been quite haphazard, I'm trying to be more consistent :}.
> > > Also, I prefer things like FreeList to free_list - I find them easier.
> > The above made me smile! I completely agree with you. However, I was
> > just trying to follow the GNU coding style. Specifically, the
> > following item is relevant here:
> > http://www.gnu.org/prep/standards_26.html#SEC26
> Erk. Well I use VI :]. cinstall isn't a Gnu Project, and I've always
> taken the standards as guidelines rather than godlines.
Since Cygwin follows the GNU coding style, I just assumed that setup.exe
- Raw text -