You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Thom May <th...@planetarytramp.net> on 2003/01/06 00:45:17 UTC
arch specific include files, the naming thereof
the header files in include/arch/*/* currently have very generic names, like
"dso.h". I got bit by this earlier when trying to specify the location of
OpenSSL, which also ships a dso.h
Would anyone have any objections to renaming them as
apr_*_private.h/apr_private_*.h ?
I volunteer to do it, just wondering if people have reasons not too?
-Thom
Re: Renaming files in cvs
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Jan 06, 2003 at 07:11:15PM +0000, Thom May wrote:
> * Justin Erenkrantz (jerenkrantz@apache.org) wrote :
> > --On Monday, January 6, 2003 4:01 PM +0100 Sander Striker
> > <st...@apache.org> wrote:
> >
> > >Ahum, this would be messing with history, like you say above.
> > >Can't we just:
> > >
> > >cvs rm foo.c
> > >cvs add foobar.c
> > >cvs ci -m "Moved foo.c to foobar.c"
> > >
> > >That seems a lot cleaner to me.
> >
> > +1. Don't touch the ,v files.
> >
> > FWIW, I personally seem to like apr_arch_*.h. -- justin
>
> ok, this sounds like a plan
> apr_arch_*.h is fine with me; and I find myself agreeing with justin and
> sander that we shouldn't move the ,v files.
Of course, everybody knows that Subversion went with a binary format just to
prevent this kind of repository mucking...
:-)
(not really, but the consideration was present...)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Renaming files in cvs, WAS: RE: arch specific include files, the naming thereof
Posted by Thom May <th...@planetarytramp.net>.
* Justin Erenkrantz (jerenkrantz@apache.org) wrote :
> --On Monday, January 6, 2003 4:01 PM +0100 Sander Striker
> <st...@apache.org> wrote:
>
> >Ahum, this would be messing with history, like you say above.
> >Can't we just:
> >
> >cvs rm foo.c
> >cvs add foobar.c
> >cvs ci -m "Moved foo.c to foobar.c"
> >
> >That seems a lot cleaner to me.
>
> +1. Don't touch the ,v files.
>
> FWIW, I personally seem to like apr_arch_*.h. -- justin
ok, this sounds like a plan
apr_arch_*.h is fine with me; and I find myself agreeing with justin and
sander that we shouldn't move the ,v files.
-Thom
Re: Renaming files in cvs, WAS: RE: arch specific include
files, the naming thereof
Posted by Justin Erenkrantz <je...@apache.org>.
--On Monday, January 6, 2003 4:01 PM +0100 Sander Striker
<st...@apache.org> wrote:
> Ahum, this would be messing with history, like you say above.
> Can't we just:
>
> cvs rm foo.c
> cvs add foobar.c
> cvs ci -m "Moved foo.c to foobar.c"
>
> That seems a lot cleaner to me.
+1. Don't touch the ,v files.
FWIW, I personally seem to like apr_arch_*.h. -- justin
Renaming files in cvs, WAS: RE: arch specific include files, the naming thereof
Posted by Sander Striker <st...@apache.org>.
> From: William A. Rowe, Jr. [mailto:wrowe@apache.org]
> Sent: Monday, January 06, 2003 3:33 PM
> At 05:45 AM 1/6/2003, Thom May wrote:
> >* Greg Stein (gstein@lyra.org) wrote :
> >> On Sun, Jan 05, 2003 at 11:59:50PM -0500, Cliff Woolley wrote:
> >> >...
> >> > My argument against using "apr_*.h" would be twofold.
> >>
> >> Fair enough... both points make sense.
> >
> >Ok, so this looks like a rough consensus on apr_private_*.h, right?
>
> I would personally prefer we stick with apr_arch_*.h ... that's a nifty idea
> and not to far from Greg's preference for apr_priv_*.h to keep it short
> and sweet. Either is my preference, apr_private_*.h seems too wordy
> when you end up with names like apr_private_thread_mutex.h
>
> >What's the best way to rename the files? cvs rm and add them again with new
> >names, or move the RCS files directly (something i've never tried and have
> >no great desire to do on a live server without someone going "yeah, that
> >works" ;-) )?
>
> If we want to keep the history, you can cp the ,v files with some caviats;
>
> 1) Start with cp apr_foo.h apr_arch_foo.h
> 2) cvs rm apr_foo.h
> 3) cvs tag -d tag apr_arch_foo.h
>
> There is one problem, apr_arch_foo.h files will be checked out along with
> apr_foo.h if you go by old checkouts by date. That isn't a huge problem
> when you consider that they are just unreferenced files (the #includes for
> that date tag will be looking for apr_foo.h.) Also consider that they reside
> in their arch/ tree and aren't installed when one builds apr.
>
> I'd say that problem is minimal, and preserving the history in an easy
> to follow manner is far more important.
Ahum, this would be messing with history, like you say above. Can't we just:
cvs rm foo.c
cvs add foobar.c
cvs ci -m "Moved foo.c to foobar.c"
That seems a lot cleaner to me.
Sander
PS. We should create a developer FAQ for this...
...or switch to Subversion ;)
Re: arch specific include files, the naming thereof
Posted by "William A. Rowe, Jr." <wr...@apache.org>.
At 05:45 AM 1/6/2003, Thom May wrote:
>* Greg Stein (gstein@lyra.org) wrote :
>> On Sun, Jan 05, 2003 at 11:59:50PM -0500, Cliff Woolley wrote:
>> >...
>> > My argument against using "apr_*.h" would be twofold.
>>
>> Fair enough... both points make sense.
>
>Ok, so this looks like a rough consensus on apr_private_*.h, right?
I would personally prefer we stick with apr_arch_*.h ... that's a nifty idea
and not to far from Greg's preference for apr_priv_*.h to keep it short
and sweet. Either is my preference, apr_private_*.h seems too wordy
when you end up with names like apr_private_thread_mutex.h
>What's the best way to rename the files? cvs rm and add them again with new
>names, or move the RCS files directly (something i've never tried and have
>no great desire to do on a live server without someone going "yeah, that
>works" ;-) )?
If we want to keep the history, you can cp the ,v files with some caviats;
1) Start with cp apr_foo.h apr_arch_foo.h
2) cvs rm apr_foo.h
3) cvs tag -d tag apr_arch_foo.h
There is one problem, apr_arch_foo.h files will be checked out along with
apr_foo.h if you go by old checkouts by date. That isn't a huge problem
when you consider that they are just unreferenced files (the #includes for
that date tag will be looking for apr_foo.h.) Also consider that they reside
in their arch/ tree and aren't installed when one builds apr.
I'd say that problem is minimal, and preserving the history in an easy
to follow manner is far more important.
Bill
Re: arch specific include files, the naming thereof
Posted by Cliff Woolley <jw...@virginia.edu>.
On Mon, 6 Jan 2003, Thom May wrote:
> Ok, so this looks like a rough consensus on apr_private_*.h, right?
> What's the best way to rename the files? cvs rm and add them again with new
cvs rm and add them again is what I'd say. There are several opinions
that come up any time we go through a file rename, but cvs rm and add them
back is the safest IMO. Otherwise you mess up history.
--Cliff
Re: arch specific include files, the naming thereof
Posted by Thom May <th...@planetarytramp.net>.
* Greg Stein (gstein@lyra.org) wrote :
> On Sun, Jan 05, 2003 at 11:59:50PM -0500, Cliff Woolley wrote:
> >...
> > My argument against using "apr_*.h" would be twofold.
>
> Fair enough... both points make sense.
Ok, so this looks like a rough consensus on apr_private_*.h, right?
What's the best way to rename the files? cvs rm and add them again with new
names, or move the RCS files directly (something i've never tried and have
no great desire to do on a live server without someone going "yeah, that
works" ;-) )?
-Thom
Re: arch specific include files, the naming thereof
Posted by Greg Stein <gs...@lyra.org>.
On Sun, Jan 05, 2003 at 11:59:50PM -0500, Cliff Woolley wrote:
>...
> My argument against using "apr_*.h" would be twofold.
Fair enough... both points make sense.
>...
> and for shits and giggles, I'll even add:
>
> +0 on using apr_arch_*.h
> -0 on using apr_os_*.h [too confusing, since for example apr_os_file_t
> would *not* be defined in apr_os_file_io.h]
+0.5 and -0, respectively.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: arch specific include files, the naming thereof
Posted by Aaron Bannert <aa...@clove.org>.
Actually, since bugs like this will be isolated to
development on new parts of APR and can't happen
in application code (these are private headers, afterall),
why don't we just namespace protect them as we come
across them, as in the case of dso.h?
-aaron
On Sunday, January 5, 2003, at 07:45 PM, Greg Stein wrote:
> Drop the "private" part. They're already private based on where they're
> located, so there isn't a need to further qualify them. I'm also
> assuming
> that we can manage to avoid conflicts between the arch-specific and the
> public file names (since we manage both namespaces).
Re: arch specific include files, the naming thereof
Posted by Cliff Woolley <jw...@virginia.edu>.
On Sun, 5 Jan 2003, Greg Stein wrote:
> Drop the "private" part. They're already private based on where they're
> located, so there isn't a need to further qualify them. I'm also assuming
> that we can manage to avoid conflicts between the arch-specific and the
> public file names (since we manage both namespaces).
>
> IOW:
> +1 on using apr_*.h
> +0.2 on using apr_priv_*.h
> +0 on using apr_private_*.h
> -0 on using apr_*_private.h
My argument against using "apr_*.h" would be twofold.
First, at least for the unix include/arch/ files, all but one or two are
named exactly the same as their public counterpart, minus the apr_ prefix.
"apr_thread_cond.h" and "thread_cond.h", for example. As you say, we can
get around this, it just means coming up with some completely different
name than "thread_cond" for one of them just to get around the fact that
we don't want to stick "priv" or "private" in the name.
Second, when you're looking at something like:
#include "apr_file_io.h"
#include "thread_cond.h"
The fact that the former has an apr_ prefix and the latter doesn't helps
to distinguish that one is a portable header and one's an arch header. If
they all have the same namespace prefix, you have to do a little more
hunting to find your include files.
So, I'll say:
+1 on using apr_private_*.h
+0.2 on using apr_priv_*.h
-0 on using apr_*.h
-0 on using apr_*_private.h
and for shits and giggles, I'll even add:
+0 on using apr_arch_*.h
-0 on using apr_os_*.h [too confusing, since for example apr_os_file_t
would *not* be defined in apr_os_file_io.h]
--Cliff
Re: arch specific include files, the naming thereof
Posted by Greg Stein <gs...@lyra.org>.
On Sun, Jan 05, 2003 at 11:45:17PM +0000, Thom May wrote:
> the header files in include/arch/*/* currently have very generic names, like
> "dso.h". I got bit by this earlier when trying to specify the location of
> OpenSSL, which also ships a dso.h
> Would anyone have any objections to renaming them as
> apr_*_private.h/apr_private_*.h ?
> I volunteer to do it, just wondering if people have reasons not too?
Drop the "private" part. They're already private based on where they're
located, so there isn't a need to further qualify them. I'm also assuming
that we can manage to avoid conflicts between the arch-specific and the
public file names (since we manage both namespaces).
IOW:
+1 on using apr_*.h
+0.2 on using apr_priv_*.h
+0 on using apr_private_*.h
-0 on using apr_*_private.h
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: arch specific include files, the naming thereof
Posted by Aaron Bannert <aa...@clove.org>.
Ouch. Yeah we need namespace protection. +1
-aaron
On Sunday, January 5, 2003, at 03:45 PM, Thom May wrote:
> the header files in include/arch/*/* currently have very generic
> names, like
> "dso.h". I got bit by this earlier when trying to specify the location
> of
> OpenSSL, which also ships a dso.h
> Would anyone have any objections to renaming them as
> apr_*_private.h/apr_private_*.h ?
> I volunteer to do it, just wondering if people have reasons not too?
> -Thom