On 30/3/21 7:56 am, Gedare Bloom wrote:
> On Fri, Mar 12, 2021 at 10:07 AM Alex White <alex.wh...@oarcorp.com> wrote:
>>
>> This adds a new behavior to the -d option which allows the creation of
>> named objdump outputs in the /tmp directory. This allows the outputs to
>> be reused on subsequent runs of covoar rather than running objdump
>> again.
> This seems to be a hackish way to optimize a behavior. Do you guys
> have a plan to improve this caching mechanism?
Agreed. If objdump and generated files is being used then caching and management
across instances of covoar will be complex but that is one of the trade-offs
when wrapping objdump.
>> - throw rld::error( "Objdump error", "generating objdump" );
>> + if (!debug || FileIsNewer( fileName.c_str(),
>> objdumpFile.name().c_str() )) {
> what's this !debug
>
> Relying on timestamps can be tricky. You all should consider how to
> create a proper cache of files, probably in the local directory from
> which this tool is run, that updates based on hashed contents of the
> source files rather than timestamps. This is for your TODO list.
The commit comment says the files are in /tmp. Using /tmp to hold files that are
not temporary seems the contradict the idea of a temporary directory.
Who cleans up the files in /tmp that are left there?
>> +{
>> + size_t idx = path.rfind('/', path.length());
> Are there any library helpers that can do this?
>
> What happens if you run this on windows? (I know the answer, this
> stuff doesn't work on windows. But it doesn't mean we shouldn't
> consider cross-platform issues?)
Windows is a supported host for this project so I hope it is tested on Windows.
Not building or not working just means someone else needs to fix the problem.
Chris
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
