rename and clean unexec.c

rename and clean unexec.c

[Dan Nicolaescu]

unexec.c is only used by MSDOS now.
It should be renamed unexecdos.c (or something like that) similar to all the other unexec files.

Also it needs a bit of a cleanup given that it's only used on MSDOS.


For example a few src/m/* files define NO_REMAP, but there's no need
for that, the only user is unexec.c
Maybe there are other #defines that can be removed in a similar fashion.

In fact almost all #ifdefs in unexec.c can be removed.

Re: rename and clean unexec.c

[Eli Zaretskii]

> From: Dan Nicolaescu <dann@gnu.org>
> Date: Wed, 28 Jul 2010 00:38:11 -0400
> 
> 
> unexec.c is only used by MSDOS now.
> It should be renamed unexecdos.c (or something like that) similar to all the other unexec files.

I don't see a need to rename it.  Renaming complicates VC forensics,
even though bzr supports renames.  This isn't the only DOS-specific
file in Emacs that doesn't have "dos" as part of its name.

If there's a need for a profound sign that unexec.c is used only by
the DOS build, we could add a COMMENT ALL IN CAPS at its beginning.

> Also it needs a bit of a cleanup given that it's only used on MSDOS.

That's fine with me.

> In fact almost all #ifdefs in unexec.c can be removed.

Probably strictly all.  The only one I'm not sure about is 
"#ifdef emacs" -- is some other package using this file, or do we
sometimes compile in Emacs without "emacs" being defined?

Anyway, I'll add to my todo to remove the ifdef's, but feel free to
beat me to it, as I have much more important jobs on my plate.

Re: rename and clean unexec.c

[Dan Nicolaescu]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Dan Nicolaescu <dann@gnu.org>
>> Date: Wed, 28 Jul 2010 00:38:11 -0400
>> 
>> 
>> unexec.c is only used by MSDOS now.
>> It should be renamed unexecdos.c (or something like that) similar to all the other unexec files.
>
> I don't see a need to rename it.  Renaming complicates VC forensics,
> even though bzr supports renames.  This isn't the only DOS-specific
> file in Emacs that doesn't have "dos" as part of its name.

By that argument we should never rename anything.
Missing renaming support was one of the main reasons that CVS was abandoned.
This file has a generic name, that's the most of obvious for someone
looking for unexec, but that file is almost always the wrong place to
look.

>
> If there's a need for a profound sign that unexec.c is used only by
> the DOS build, we could add a COMMENT ALL IN CAPS at its beginning.
>
>> Also it needs a bit of a cleanup given that it's only used on MSDOS.
>
> That's fine with me.
>
>> In fact almost all #ifdefs in unexec.c can be removed.
>
> Probably strictly all.  The only one I'm not sure about is 
> "#ifdef emacs" -- is some other package using this file, or do we
> sometimes compile in Emacs without "emacs" being defined?
>
> Anyway, I'll add to my todo to remove the ifdef's, but feel free to
> beat me to it, as I have much more important jobs on my plate.

I'll remove the ones that were once machine/system properties, so that
they can completely disappear from the tree.  I can't do it all, I
don't know enough about what msdos wants there.

Re: rename and clean unexec.c

[Óscar Fuentes]

Dan Nicolaescu <dann@gnu.org> writes:

>> I don't see a need to rename it.  Renaming complicates VC forensics,
>> even though bzr supports renames.  This isn't the only DOS-specific
>> file in Emacs that doesn't have "dos" as part of its name.
>
> By that argument we should never rename anything.
> Missing renaming support was one of the main reasons that CVS was abandoned.
> This file has a generic name, that's the most of obvious for someone
> looking for unexec, but that file is almost always the wrong place to
> look.

Speaking as someone who is getting familiar with the code base, it is
useful to see a hint on the name about its platform-specific nature. I
dedicated some time to partition the source files among shared,
platform-specific, feature-specific, etc and it could be done a bit
faster if they had more informative names. It is nothing terribly
important, though. It is like renaming a function or variable with a
cryptic name. Helps on some ways and hurts on others. IMHO it is almost
always a good thing, as any code cleanup.

Putting some comment at the top of the file hurts nobody and helps a
lot, though. That practice is already used on several files.

[snip]

Re: rename and clean unexec.c

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Dan Nicolaescu <dann@gnu.org>
> Date: Wed, 28 Jul 2010 15:46:12 -0400
> 
> I can't do it all, I don't know enough about what msdos wants there.

That part's on me.

Re: rename and clean unexec.c

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Wed, 28 Jul 2010 22:13:16 +0200
> 
> Speaking as someone who is getting familiar with the code base, it is
> useful to see a hint on the name about its platform-specific nature.

unexec.c is not DOS-specific.  It is for any platform that uses COFF.
It just so happens that MSDOS is the only one that still does.

> Putting some comment at the top of the file hurts nobody and helps a
> lot, though. That practice is already used on several files.

I will do that, then, when I have time.

Re: rename and clean unexec.c

[Dan Nicolaescu]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Óscar Fuentes <ofv@wanadoo.es>
>> Date: Wed, 28 Jul 2010 22:13:16 +0200
>> 
>> Speaking as someone who is getting familiar with the code base, it is
>> useful to see a hint on the name about its platform-specific nature.
>
> unexec.c is not DOS-specific.  It is for any platform that uses COFF.
> It just so happens that MSDOS is the only one that still does.

Then let's call it unexcoff.c then so that it follows some kind of
rule like all the other unexec files.  It's not very logical to refuse
to change the least used one.

Re: rename and clean unexec.c

[Eli Zaretskii]

> From: Dan Nicolaescu <dann@gnu.org>
> Date: Wed, 28 Jul 2010 18:55:45 -0400
> Cc: Óscar Fuentes <ofv@wanadoo.es>, emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Óscar Fuentes <ofv@wanadoo.es>
> >> Date: Wed, 28 Jul 2010 22:13:16 +0200
> >> 
> >> Speaking as someone who is getting familiar with the code base, it is
> >> useful to see a hint on the name about its platform-specific nature.
> >
> > unexec.c is not DOS-specific.  It is for any platform that uses COFF.
> > It just so happens that MSDOS is the only one that still does.
> 
> Then let's call it unexcoff.c then so that it follows some kind of
> rule like all the other unexec files.  It's not very logical to refuse
> to change the least used one.

Why is it so important to rename this file?  I'm not against renaming
in general, if there is a good reason.  I just don't see any such
reasons in this case.  Without a good reason, renaming is just a
nuisance, albeit a minor one.

Re: rename and clean unexec.c

[Dan Nicolaescu]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Dan Nicolaescu <dann@gnu.org>
>> Date: Wed, 28 Jul 2010 18:55:45 -0400
>> Cc: Óscar Fuentes <ofv@wanadoo.es>, emacs-devel@gnu.org
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> From: Óscar Fuentes <ofv@wanadoo.es>
>> >> Date: Wed, 28 Jul 2010 22:13:16 +0200
>> >> 
>> >> Speaking as someone who is getting familiar with the code base, it is
>> >> useful to see a hint on the name about its platform-specific nature.
>> >
>> > unexec.c is not DOS-specific.  It is for any platform that uses COFF.
>> > It just so happens that MSDOS is the only one that still does.
>> 
>> Then let's call it unexcoff.c then so that it follows some kind of
>> rule like all the other unexec files.  It's not very logical to refuse
>> to change the least used one.
>
> Why is it so important to rename this file?  I'm not against renaming

For long term maintainability.
Good, suggestive file names are good for maintainability.

When we have a rule and a single file does not follow it, it not good.
We finally have the right support for renaming so there's not reason
to keep a very old name that's not accurate anymore and it's the wrong
place to look for the "unexec" function for close to (100% -1person)
of the developers.

Re: rename and clean unexec.c

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Óscar Fuentes <ofv@wanadoo.es>
>> Date: Wed, 28 Jul 2010 22:13:16 +0200
>> 
>> Speaking as someone who is getting familiar with the code base, it is
>> useful to see a hint on the name about its platform-specific nature.
>
> unexec.c is not DOS-specific.  It is for any platform that uses COFF.

Also for a.out.  It's in fact the original unexec implementation.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: rename and clean unexec.c

[Eli Zaretskii]

> Cc: ofv@wanadoo.es,  emacs-devel@gnu.org
> From: Dan Nicolaescu <dann@gnu.org>
> Date: Wed, 28 Jul 2010 23:21:40 -0400
> 
> > Why is it so important to rename this file?
> 
> For long term maintainability.
> Good, suggestive file names are good for maintainability.

But we've been living with this file, in parallel with other unex*,
for ages.  Why is it suddenly a problem now?  What changed?

Re: rename and clean unexec.c

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> > Why is it so important to rename this file?
>> 
>> For long term maintainability.
>> Good, suggestive file names are good for maintainability.
>
> But we've been living with this file, in parallel with other unex*,
> for ages.  Why is it suddenly a problem now?  What changed?

The version control tool, I guess. With CVS renaming is very
inconvenient. Not so with bzr.

Re: rename and clean unexec.c

[Dan Nicolaescu]

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: ofv@wanadoo.es,  emacs-devel@gnu.org
>> From: Dan Nicolaescu <dann@gnu.org>
>> Date: Wed, 28 Jul 2010 23:21:40 -0400
>> 
>> > Why is it so important to rename this file?
>> 
>> For long term maintainability.
>> Good, suggestive file names are good for maintainability.
>
> But we've been living with this file, in parallel with other unex*,
> for ages.  Why is it suddenly a problem now?  What changed?

This file was used before by other platforms that we've removed support for.
It is now used by a single platform.
Before we did not rename files because CVS could not do it right.
I've worked very hard at removing decades of accumulated cruft, please
don't stand in the way for no good reason.

Re: rename and clean unexec.c

[Eli Zaretskii]

> From: Dan Nicolaescu <dann@gnu.org>
> Date: Thu, 29 Jul 2010 14:19:21 -0400
> Cc: emacs-devel@gnu.org
> 
> I've worked very hard at removing decades of accumulated cruft, please
> don't stand in the way for no good reason.

With all due respect, this is not your private war, and you aren't the
only one whose opinions matter.  And unexec.c isn't cruft.

Re: rename and clean unexec.c

[Dan Nicolaescu]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Dan Nicolaescu <dann@gnu.org>
>> Date: Thu, 29 Jul 2010 14:19:21 -0400
>> Cc: emacs-devel@gnu.org
>> 
>> I've worked very hard at removing decades of accumulated cruft, please
>> don't stand in the way for no good reason.
>
> With all due respect, this is not your private war, and you aren't the

Please don't aggravate a simple discussion by adding words like "war".

> only one whose opinions matter.  And unexec.c isn't cruft.

The name of that file is currently almost the only remaining cruft.
Please look at the history of the file and see how much cruft was
removed from there in the last 2 years.

I am not sure why are so opposed to this.

Let me repeat the arguments.
We have a generic function "unexec", most programmers would look for
the normal implementation in unexec.c, but that's the wrong place for
everyone, except you.

We have these files:
unexaix.c
unexcw.c
unexec.c
unexelf.c
unexhp9k800.c
unexmacosx.c
unexsol.c
unexw32.c

for all the name obviously tells what they are used for, except for unexec.c 

So this is mostly about what is most useful for the vast majority of people.

Re: rename and clean unexec.c

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Dan Nicolaescu <dann@gnu.org>
> Date: Thu, 29 Jul 2010 17:18:02 -0400
> 
> I am not sure why are so opposed to this.

Not "so opposed", just opposed.  I'm opposed in principle to every
cosmetic change that doesn't have a very good reason.  That's because
such changes obscure real code changes and make forensics harder.

> Let me repeat the arguments.
> We have a generic function "unexec", most programmers would look for
> the normal implementation in unexec.c, but that's the wrong place for
> everyone, except you.

I don't expect anyone to look at unexec, unless they already know
quite a lot about it, including the fact that different ABIs need
different versions of it.

Re: rename and clean unexec.c

[Dan Nicolaescu]

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: emacs-devel@gnu.org
>> From: Dan Nicolaescu <dann@gnu.org>
>> Date: Thu, 29 Jul 2010 17:18:02 -0400
>> 
>> I am not sure why are so opposed to this.
>
> Not "so opposed", just opposed.  I'm opposed in principle to every
> cosmetic change that doesn't have a very good reason.  

Maintainability is a very good reason.   Keeping bad names is not.


> That's because
> such changes obscure real code changes and make forensics harder.

Can you please explain exactly how renaming a file managed by a decent
VCS makes forensics harder?

Re: rename and clean unexec.c

[Stefan Monnier]

I would agree to renaming it unexcoff.c but not unexdos.c, because file
names (like function names) should describe what the file/function does,
rather than how it's used.
This said, I don't see a strong need to renaming it.


        Stefan

Re: rename and clean unexec.c

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Dan Nicolaescu <dann@gnu.org>
> Date: Fri, 30 Jul 2010 03:37:30 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Cc: emacs-devel@gnu.org
> >> From: Dan Nicolaescu <dann@gnu.org>
> >> Date: Thu, 29 Jul 2010 17:18:02 -0400
> >> 
> >> I am not sure why are so opposed to this.
> >
> > Not "so opposed", just opposed.  I'm opposed in principle to every
> > cosmetic change that doesn't have a very good reason.  
> 
> Maintainability is a very good reason.   Keeping bad names is not.

It should be obvious by now that we disagree on how much this
particular renaming will contribute to better maintainability.

> > That's because
> > such changes obscure real code changes and make forensics harder.
> 
> Can you please explain exactly how renaming a file managed by a decent
> VCS makes forensics harder?

I can only speak about Bazaar, as I'm not familiar enough with
similar facilities of other dVCSs.

The tools I use for forensics are:

  . bzr log
  . bzr diff
  . bzr annotate
  . bzr bisect (and bzr revert in general)
  . ChangeLog entries
  . related discussions on emacs-devel and bug-gnu-emacs

"bzr diff" and "bzr annotate" indeed support renaming nicely and
transparently, but they are never enough to fully investigate the
reasons for some change.  They just show what was changed and when,
and who did that, so they are only the starting point.

A minor gripe about "bzr bisect" and "bzr revert" is that they will
move the renamed (or deleted) files to alternate names, which is fine,
but requires one to be alert in order to prevent all kind of weird
errors and warnings down the line.

The rest of the tools I use have problems with renaming:

  . The latter two need that you know about the renaming, or else you
    won't hit relevant information in a search.
  . The first one generally shows a slightly edited copy of a
    ChangeLog entry, so it doesn't support renaming well, either; even
    the entry for the rename itself will only mention the renaming if
    the committer remembered to state that, i.e. it's prone to human
    error.

In addition, "bzr log" seems to have a bug that rears its ugly head
with renamed files.  Observe:

  $ bzr log -c26091 --long src/s/usg5-4-common.h
  bzr: ERROR: Path unknown at end or start of revision range: src/s/usg5-4-common.h

(It works if I use usg5-4.h, the name it had when revno 26091 was
committed.)

Granted, these are not acute problems, more like annoyances, but if
you are in a hurry and need to find the information quickly and
efficiently, they could defeat you.

Again, I don't object to renaming in general.  We renamed (or moved)
quite a few files lately, and I don't remember myself objecting to
even one of them.  I just don't see a good reason in this particular
case.

Now, I hope that my reasons are clear, as are yours.  If only the two
of us have opinions on this matter, we could go on arguing forever.  I
think at this point it would be good to hear opinions from others,
preferably Stefan and/or Chong.

Re: rename and clean unexec.c

[Dan Nicolaescu]

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: emacs-devel@gnu.org
>> From: Dan Nicolaescu <dann@gnu.org>
>> Date: Fri, 30 Jul 2010 03:37:30 -0400
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> Cc: emacs-devel@gnu.org
>> >> From: Dan Nicolaescu <dann@gnu.org>
>> >> Date: Thu, 29 Jul 2010 17:18:02 -0400
>> >> 
>> >> I am not sure why are so opposed to this.
>> >
>> > Not "so opposed", just opposed.  I'm opposed in principle to every
>> > cosmetic change that doesn't have a very good reason.  
>> 
>> Maintainability is a very good reason.   Keeping bad names is not.
>
> It should be obvious by now that we disagree on how much this
> particular renaming will contribute to better maintainability.

You might want to answer this question: how many people would change
and look at unexecoff.c?  
Based on the history of changes to that file the answer is zero.  Most
of the changes in many years have been to remove generic unexec
support for various other systems.
That means a bad name is a inconvenience to EVERYONE (a minor
inconvenience, but it's an inconvenience nevertheless)

>
>> > That's because
>> > such changes obscure real code changes and make forensics harder.
>> 
>> Can you please explain exactly how renaming a file managed by a decent
>> VCS makes forensics harder?
>
> I can only speak about Bazaar, as I'm not familiar enough with
> similar facilities of other dVCSs.
>
> The tools I use for forensics are:
>
>   . bzr log
>   . bzr diff
>   . bzr annotate

For these you would be much better off using C-x v [l=g].
It's MUCH quicker to look around and you can get access to one type
view when using another one.
IMO there's no reason to EVER use bzr annotate from the command line, C-x v g 
offers so many more very useful features.

>   . bzr bisect (and bzr revert in general)
>   . ChangeLog entries
>   . related discussions on emacs-devel and bug-gnu-emacs


> "bzr diff" and "bzr annotate" indeed support renaming nicely and
> transparently, but they are never enough to fully investigate the
> reasons for some change.  They just show what was changed and when,
> and who did that, so they are only the starting point.
>
> A minor gripe about "bzr bisect" and "bzr revert" is that they will
> move the renamed (or deleted) files to alternate names, which is fine,
> but requires one to be alert in order to prevent all kind of weird
> errors and warnings down the line.
>
> The rest of the tools I use have problems with renaming:
>
>   . The latter two need that you know about the renaming, or else you
>     won't hit relevant information in a search.
>   . The first one generally shows a slightly edited copy of a
>     ChangeLog entry, so it doesn't support renaming well, either; even
>     the entry for the rename itself will only mention the renaming if
>     the committer remembered to state that, i.e. it's prone to human
>     error.
>
> In addition, "bzr log" seems to have a bug that rears its ugly head
> with renamed files.  Observe:

Given that this is a bug in bzr tool, isn't it a bad idea to base
emacs file names policies on bugs in tools??

>   $ bzr log -c26091 --long src/s/usg5-4-common.h
>   bzr: ERROR: Path unknown at end or start of revision range: src/s/usg5-4-common.h
>
> (It works if I use usg5-4.h, the name it had when revno 26091 was
> committed.)

Again, if you use C-x v l, you can just use C-s to find revision
26091, and from there you can look at the diff, annotate and actual
file with a single key.

Re: rename and clean unexec.c

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

[snip]

>   . ChangeLog entries
>   . related discussions on emacs-devel and bug-gnu-emacs

[snip]

> The rest of the tools I use have problems with renaming:
>
>   . The latter two need that you know about the renaming, or else you
>     won't hit relevant information in a search.

That reasoning would preclude renaming files, functions, variables and
what-not, right? It favors code stagnation.

BTW, the contents of unexec.c is not cruft, its file name is.

[snip]

Re: rename and clean unexec.c

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Wed, 04 Aug 2010 18:55:48 +0200
> 
> That reasoning would preclude renaming files, functions, variables and
> what-not, right?

Not if you read what I wrote in this thread (as opposed to only what
you want to read to make the point of your liking).

Re: rename and clean unexec.c

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> That reasoning would preclude renaming files, functions, variables and
>> what-not, right?
>
> Not if you read what I wrote in this thread

Sorry, as we are on the 18th deep level of the thread, maybe I'm
missing something. Perhaps your are referring to this:

From: Eli Zaretskii <eliz@gnu.org>
Date: Thu, 29 Jul 2010 06:06:27 +0300

> I'm not against renaming in general, if there is a good reason.

I wonder what's a good reason for you.

> (as opposed to only what you want to read to make the point of your
> liking).

Ha!

Emacs would benefit from any effort towards cleaning the code. There is
cruft everywhere, including #if 0 and #if 1, functions several hundred
lines long sprinkled with dozens of preprocessor conditionals, places
with piles of accumulated hacks for adapting the code to new
environments or for fixing bugs (instead of refactorizing the code),
special cases for dead systems, files which are on the tens of thousands
line count containing loosely related stuff, names that badly convey the
purpose of the named object (unexec.c is a mild example, we could add
xdisp.c and lots of functions with _x_ in its name when actually they
apply to other windowing systems) and so on.

The point of my liking is that somebody is trying to do something about
that. If you object to renaming a small platform-specific file, what
would you say if he wants to rename several core functions?

Being allowed to easily do forensics is good. Having a clean, friendly
code base is *much* better. You would say that unexec.c is just a tiny
inconvenience, but Emacs has hundreds of such tiny inconveniences, and
that amounts to a big annoyance. Please remember that Emacs is not in
maintenance mode by a few veteran hackers, it is supposed to be an
evolving project with a need for new programmers.

Re: rename and clean unexec.c

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Wed, 04 Aug 2010 23:58:38 +0200
> 
> The point of my liking is that somebody is trying to do something about
> that. If you object to renaming a small platform-specific file, what
> would you say if he wants to rename several core functions?
> 
> Being allowed to easily do forensics is good. Having a clean, friendly
> code base is *much* better. You would say that unexec.c is just a tiny
> inconvenience, but Emacs has hundreds of such tiny inconveniences, and
> that amounts to a big annoyance. Please remember that Emacs is not in
> maintenance mode by a few veteran hackers, it is supposed to be an
> evolving project with a need for new programmers.

I wonder why you thought I deserved this lecture.

Re: rename and clean unexec.c

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Fri, 30 Jul 2010 11:12:58 +0200
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> 
> I would agree to renaming it unexcoff.c but not unexdos.c, because file
> names (like function names) should describe what the file/function does,
> rather than how it's used.

I took this as tending towards Dan's request, and renamed the file to
unexcoff.c.

Would someone who has the right version of Autoconf handy please
regenerate `configure'?  TIA

Re: rename and clean unexec.c

[Eli Zaretskii]

> Date: Wed, 28 Jul 2010 23:46:58 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> > Cc: emacs-devel@gnu.org
> > From: Dan Nicolaescu <dann@gnu.org>
> > Date: Wed, 28 Jul 2010 15:46:12 -0400
> > 
> > I can't do it all, I don't know enough about what msdos wants there.
> 
> That part's on me.

I have a question here: do we want to strip unexcoff.c from everything
except what the MSDOS build needs?  That would mean any platform that
will need COFF support will have to look for the code in prior revnos.
I don't mind, assuming others think it's the right thing.  (Is it
plausible that some future, e.g., mobile platform will use COFF?)

And what to do with "#ifdef emacs" -- should I leave the !emacs
branches or delete them?

Re: rename and clean unexec.c

[Dan Nicolaescu]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Date: Fri, 30 Jul 2010 11:12:58 +0200
>> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
>> 
>> I would agree to renaming it unexcoff.c but not unexdos.c, because file
>> names (like function names) should describe what the file/function does,
>> rather than how it's used.
>
> I took this as tending towards Dan's request, and renamed the file to
> unexcoff.c.

Thanks!

> Would someone who has the right version of Autoconf handy please
> regenerate `configure'?  TIA

Done.  (It seems we are using autoconf-2.66 now)

Re: rename and clean unexec.c

[Dan Nicolaescu]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Wed, 28 Jul 2010 23:46:58 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: emacs-devel@gnu.org
>> 
>> > Cc: emacs-devel@gnu.org
>> > From: Dan Nicolaescu <dann@gnu.org>
>> > Date: Wed, 28 Jul 2010 15:46:12 -0400
>> > 
>> > I can't do it all, I don't know enough about what msdos wants there.
>> 
>> That part's on me.
>
> I have a question here: do we want to strip unexcoff.c from everything
> except what the MSDOS build needs?  That would mean any platform that
> will need COFF support will have to look for the code in prior revnos.
> I don't mind, assuming others think it's the right thing.  (Is it

IMHO that's the right balance: it places the burden on (maybe) dealing
with the code to whoever wants to do that in the future.

> plausible that some future, e.g., mobile platform will use COFF?)

Doubtful, every non-MAC, non-MS platform is ELF nowadays... 

> And what to do with "#ifdef emacs" -- should I leave the !emacs
> branches or delete them?

Remove.

Re: rename and clean unexec.c

[Stefan Monnier]

>> I would agree to renaming it unexcoff.c but not unexdos.c, because file
>> names (like function names) should describe what the file/function does,
>> rather than how it's used.

> I took this as tending towards Dan's request,

It wasn't the intention, I had no preference either way.

> and renamed the file to unexcoff.c.

Fine, thanks for closing this thread.


        Stefan

Re: rename and clean unexec.c

[Stefan Monnier]

> Doubtful, every non-MAC, non-MS platform is ELF nowadays... 

a.out still seems to be in use on some home-routers.


        Stefan

Re: rename and clean unexec.c

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Dan Nicolaescu <dann@gnu.org>
> Date: Thu, 05 Aug 2010 14:46:00 -0400
> 
> >> > I can't do it all, I don't know enough about what msdos wants there.
> >> 
> >> That part's on me.
> >
> > I have a question here: do we want to strip unexcoff.c from everything
> > except what the MSDOS build needs?  That would mean any platform that
> > will need COFF support will have to look for the code in prior revnos.
> > I don't mind, assuming others think it's the right thing.  (Is it
> 
> IMHO that's the right balance: it places the burden on (maybe) dealing
> with the code to whoever wants to do that in the future.
> 
> > plausible that some future, e.g., mobile platform will use COFF?)
> 
> Doubtful, every non-MAC, non-MS platform is ELF nowadays... 

No MS platform ever used COFF, btw.  Windows uses pe-coff, which is
not exactly COFF.  The DJGPP project, which the DOS build uses,
produces COFF executables, but it needs a special loader to run it on
DOS, because DOS does not understand COFF.

> > And what to do with "#ifdef emacs" -- should I leave the !emacs
> > branches or delete them?
> 
> Remove.

Done.

I left alone the "#ifdef MSDOS" parts, since I don't want this file to
support only the DOS build (as discussed in this thread).  I also left
alone a couple of lines specific to the a.out support.

In addition, I needed to remove a few lines of code that were
mistakenly left in the file when NO_REMAP was removed.

For the record, the question I asked on the GDB forum regarding a
possibility that some other platforms use or will use COFF, and the
responses (which indicated that this is improbable), are in the thread
which you can read here:

  http://sourceware.org/ml/gdb/2010-08/msg00040.html