On Fri, Jun 24, 2011 at 1:37 PM, Mike Frysinger <[email protected]> wrote:
> On Fri, Jun 24, 2011 at 11:05, Jie Zhang wrote:
>> On Thu, Jun 23, 2011 at 7:21 PM, Mike Frysinger wrote:
>>> so based on the automake feedback, the suggestion is to keep bypassing the
>>> issue via variables.  here's the latest patch which includes fixes from Jie.
>>>
>>> on the svf side, there's no extra dependencies as everything in that subdir
>>> needs the bison header files.  on the bsdl side, there is one extra
>>> dependency: bsdl.c depends on the bison headers.  but i dont think it's 
>>> worth
>>> fretting about since it only comes up when checking sources out from the 
>>> tree
>>> and regenerating autotools the first time.
>>>
>>> --- src/bsdl/Makefile.am        (revision 1910)
>>> +++ src/bsdl/Makefile.am        (working copy)
>>> @@ -53,12 +53,9 @@
>>>  # additional dependencies
>>>  # - *_flex files must be processed after their *_bison counterparts
>>>  #   to ensure that *_bison.h is present
>>> -libbsdl_flex_la-vhdl_flex.$(OBJEXT): vhdl_bison.h
>>> -libbsdl_flex_la-bsdl_flex.$(OBJEXT): bsdl_bison.h
>>> -bsdl_sem.$(OBJEXT): bsdl_bison.h
>>> -
>>> -vhdl_bison.h: vhdl_bison.c
>>> -bsdl_bison.h: bsdl_bison.c
>>> +$(libbsdl_la_OBJECTS) $(libbsdl_flex_la_OBJECTS): bsdl_bison.h vhdl_bison.h
>>> +vhdl_bison.h: vhdl_bison.c ; @true
>>> +bsdl_bison.h: bsdl_bison.c ; @true
>>>
>>>  AM_LFLAGS = -i
>>
>> Will this be better?
>>
>> # additional dependencies
>> # - *_flex files must be processed after their *_bison counterparts
>> #   to ensure that *_bison.h is present
>> # These dependencies are written as below because Automake blah blah blah...
>>
>> VHDL_FLEX_LO = libbsdl_flex_la-vhdl_flex.lo
>> BSDL_FLEX_LO = libbsdl_flex_la-bsdl_flex.lo
>> BSDL_SEM_LO = bsdl_sem.lo
>>
>> $(VHDL_FLEX_LO): vhdl_bison.h
>> $(BSDL_FLEX_LO): bsdl_bison.h
>> $(BSDL_SEM_LO): bsdl_bison.h
>
> what about the .o/.$(OBJEXT) files ?  i'm not familiar with all the
> libtool code paths which is why i was leaning towards $(..._OBJECTS)
> rather than hardcoding the object names.

In the generated Makefile, it seems these $(xxx_OBJECTS) contain only
.lo files. And "OBJEXT = lo" had been used for more than 2 years. So I
think this hardcoding is safe.


Jie

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a 
definitive record of customers, application performance, security 
threats, fraudulent activity and more. Splunk takes this data and makes 
sense of it. Business sense. IT sense. Common sense.. 
http://p.sf.net/sfu/splunk-d2d-c1
_______________________________________________
UrJTAG-development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/urjtag-development

Reply via email to