On Fri, Jun 24, 2011 at 16:56, Jie Zhang wrote: > On Fri, Jun 24, 2011 at 1:37 PM, Mike Frysinger 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.
well, OBJEXT hardcoding has been broken for more than 2 years :P in thinking about how libtool works, i think using .lo names is fine. this is the "libtool output" which libtool always generates. the .o/.obj/etc... is output by libtool itself before creating the .lo. so yes, depending on ".lo" is fine by me. i'll send a new patch with your suggestions incorporated. -mike ------------------------------------------------------------------------------ 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
