So, after rereading this message I just realized why stapl is missing from
the command list, in this particular instance. generated_cmd_list.h is
generated from libcmd_la_OBJECTS, which does not include cmd_stapl (or
cmd_svf or cmd_bsdl) unless they are ENABLED. The default profile only
enables bsdl and svf, not stapl, so when generated_cmd_list.h was generated
it never even saw cmd_stapl.c. I'm not sure if there is a "correct" fix
for this ,but I'm pretty happy with my patch as a workaround.
Nick
On Sun, Aug 3, 2014 at 9:56 AM, Mike Frysinger <vap...@gentoo.org> wrote:
> On Sat 02 Aug 2014 21:55:56 Nick B wrote:
> > On Centos6 I was unable to generate a urjtag binary that accepted the
> stapl
> > option. After some digging I tracked it back to generated_cmd_list.h not
> > being regenerated, because while a new file had been added to the list of
> > files it would be generated from, the generated_cmd_list.h file was newer
> > than any of them. This patch adds generated_cmd_list.h.stamp to PHONY,
> > which avoids this problem by always regenerating the file.
>
> you've lost me. generated_cmd_list.h is generated whenever one of the
> cmd_*.c
> files is updated, and it depends on all of the cmd_*.c files regardless of
> the
> configure options. its output is also the same regardless of configure
> options. so how did you have a generated header that did not reflect all
> of
> the cmd files ?
> -mike
------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
UrJTAG-development mailing list
UrJTAG-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/urjtag-development
