James Carlson wrote:
>
> I was commenting on Ali's seeming misunderstanding of my original
> comment; he brought up adding -w enhancements, when I was merely
> saying that renaming files (if that's how the changes are wrought)
> shouldn't be a serious concern.
>
You're right --- it never occurred
Mark J. Nelson writes:
> James Carlson wrote:
> > Ali Bahrami writes:
> >> Of course this is not perfectly seamless --- the person integrating
> >> process_mapfile will still be confronted with some confusing errors,
> >> and will have to augment the exception file to make them go away.
> >
> > Ri
Ali Bahrami writes:
> Of course this is not perfectly seamless --- the person integrating
> process_mapfile will still be confronted with some confusing errors,
> and will have to augment the exception file to make them go away.
Right; there'll need to be some sort of guidance to other gatelings
a
Ali Bahrami writes:
> - Files that are not actual linker mapfiles
> - A couple of template mapfiles that are processed
> via their makefiles to generate mapfiles (mdb, libelfsign)
> - A small number of mapfiles that don't set any versioning
> information, but ra
James Carlson wrote:
> Ali Bahrami writes:
>> Of course this is not perfectly seamless --- the person integrating
>> process_mapfile will still be confronted with some confusing errors,
>> and will have to augment the exception file to make them go away.
>
> Right; there'll need to be some sort of
James Carlson wrote:
> Ali Bahrami writes:
>> - Files that are not actual linker mapfiles
>> - A couple of template mapfiles that are processed
>>via their makefiles to generate mapfiles (mdb, libelfsign)
>> - A small number of mapfiles that don't set any versioning
>>
Richard Lowe wrote:
...
> File a bug, please.
>
> -- Rich
I just filed:
6798660 Cadmium .NOT file processing problem with CWD relative file paths
I marked it P4, because the world isn't going to end over
this one. However, my personal priority is somewhat higher, as
I'd like to get this mapfil
> Another thing I like is that the exception_lists approach that Mark
> came up with is general to all the cadmium tools, instead of being
> just a mapfilechk specific thing.
This is also the first step (not sure if we'll ever take others) to
consolidating some exception lists in a repository-c
Danek Duvall wrote:
> On Tue, Jan 27, 2009 at 06:07:29PM -0700, Ali Bahrami wrote:
>
>> mapfilechk examines any file with a name that matches '*mapfile*',
>> and ignores all others. However, there are a small number of files
>> in OSnet that match this pattern that are not actually mapfiles.
>> Fo
Mike Kupfer wrote:
> I'm a little confused. Are you using the .NOT mechanism so that your
> mapfilechk code will avoid known files? Or are you creating an actual
> .NOT file that lists the things mapfilechk must skip? Assuming we fix
> the path issue in Cadmium, what will users see after your pu
Ali Bahrami writes:
> The problem I'm encountering is that the list of files returned by
> _buildfilelist() is relative to the working directory, while the
> list of file path exceptions needs to be relative to the workspace
> root. Consequently, exclude() only matches if my working directory
> i
On Tue, Jan 27, 2009 at 06:07:29PM -0700, Ali Bahrami wrote:
> mapfilechk examines any file with a name that matches '*mapfile*',
> and ignores all others. However, there are a small number of files
> in OSnet that match this pattern that are not actually mapfiles.
> For instance, mapfilechk itsel
I've been working on adding a new linker mapfile check
(mapfilechk) to cadmium, patterned on cddlchk, as detailed
in the CR:
6785284 Mapfile versioning rules need to be more visible to gatelings
In a nutshell, there will be a standard comment in all of the OSnet
link-editor mapfiles, and
I'm a little confused. Are you using the .NOT mechanism so that your
mapfilechk code will avoid known files? Or are you creating an actual
.NOT file that lists the things mapfilechk must skip? Assuming we fix
the path issue in Cadmium, what will users see after your putback?
mike
14 matches
Mail list logo
