gnupic: Re: [gnupic] gplink and .lst files
Subject:
Re: [gnupic] gplink and .lst files
From:
Craig Franklin ####@####.####
Date:
28 Mar 2006 07:05:05 +0100
Message-Id: <4428D375.3010507@users.sourceforge.net>
George M. Gallant, Jr. wrote:
>Craig,
>
>The difference is gplink has a -l option which is
>is supposed to "Disable list file output." Thanks
>for pointing out a weakness in gpasm.
>
>
>
I forgot how much fun this is. I am glad to be back :)
So you have a project whose target is my_build.hex. You want to add a
-l to gplink to prevent it from generating a list file and keep another
file not generated by gplink but named my_build.lst in the same
project. I will ask again, why? Are you using some other method to
generate a list file?
A few years back I was working on fixing a gputils bug. Can't remember,
but I think it was in the COD files. Those files are managed the same
way the list files are. Problem was the COD file I was debugging didn't
match the hex file because the COD file was being suppressed, but the
output file wasn't being deleted. A very frustrating way to waste
time. If it happens to me, I am sure others have experienced it.
If you have a real good reason not to do it, I am listening. So far the
only thing I am hearing is you don't like it.
>George
>
>On Mon, 2006-03-27 at 20:57 -0600, Craig Franklin wrote:
>
>
>
>>George M. Gallant, Jr. wrote:
>>
>>
>>
>>>Craig,
>>>
>>>I find 2 problems with the current scheme:
>>>
>>> 1. gpasm and gplink both produce xxx.lst files.
>>>
>>>
>>>
>>>
>>They also both generate .hex and .cod files.
>>
>>
>>
>>> 2. gplink deletes the xxx.lst file even if it is not writing one
>>>itself.
>>>
>>>
>>>
>>>
>>gpasm deletes xxx.lst files even if it is not writing one too.
>>
>>Here is the problem with your scheme: I compile my project with the
>>list file enabled. Then later suppress the list file output and keep
>>building the project. The list file won't match any of the current
>>outputs. This is confusing at a minimum.
>>
>>If you want to keep a file, whether it is a hex, cod, list,... rename it
>>or move it. Why do you want to keep a list file that doesn't match any
>>of the other outputs?
>>
>>
>>
>>>George
>>>
>>>On Mon, 2006-03-27 at 19:52 -0600, Craig Franklin wrote:
>>>
>>>
>>>
>>>
>>>
>>>>The current behavior is to prevent old stale list files from being
>>>>confused with current hex files. All the gputils tools behave this way
>>>>for all file types.
>>>>
>>>>Best thing to do is to rename your file. This will also help prevent
>>>>gputils from over writing your special list file.
>>>>
>>>>George M. Gallant, Jr. wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>I typically use the -l option to gplink to inhibit the creation of the
>>>>>composite .lst file.
>>>>>A side effect is gplink deletes the existing .lst file. Moving the the
>>>>>code at approx
>>>>>lines 267-268 264 makes seems to correct this behavior.
>>>>>
>>>>>New code:
>>>>>
>>>>>void write_lst(void) {
>>>>>gp_symbol_type *symbol = state.object->symbols;
>>>>>gp_aux_type *aux;
>>>>>gp_boolean first_time = true;
>>>>>
>>>>>if(!state.lst.enabled)
>>>>> return;
>>>>>
>>>>>lst_init();
>>>>>
>>>>>list_enabled = true;
>>>>>
>>>>>Thanks,
>>>>> George
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: ####@####.####
>>>>For additional commands, e-mail: ####@####.####
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: ####@####.####
>>For additional commands, e-mail: ####@####.####
>>
>>
>>
>
>
>
