fix Makefile.am

---
 src/Makefile.am | 9 ---------
 1 file changed, 9 deletions(-)

Hi Alexander,

thanks for your patch submission! I ran into the same problem just
yesterday.

It is true that the lines your patch removes can be removed. However, the patch
alone does not solve the build problem for me. In a clean checkout with the
patch applied, I do still get the error:

  hnbgw_ranap.c:36:28: fatal error: ranap_ies_defs.h: No such file or directory
   #include "ranap_ies_defs.h"

It first appears that the problem is related to the fact that asn1tostruct.py
creates all of the *_ies_defs.h, *_decoder.c and *_encoder.c files in one step.
However, taking a closer look, the root cause for the missing ranap_ies_defs.h
is: automake seems unaware that the ranap sources need to be built. Having them
in hnbgw_SOURCES alone is not enough, apparently. Looking at a verbose build
log revealed that the asn1tostruct.py was never called on the RANAP asn. I'm
still not sure why the hnbap and rua were generated and the ranap was omitted
(there seems to be no difference to ranap), but adding a BUILT_SOURCES to
Makefile.am solves the problem for me.

The fact that multiple files are built from one step should actually not be a
problem: all three files get generated from the first dependency, after which
the remaining files are already newer than the asn file -> "nothing to be done".

So I'm committing your patch to remove extraneous lines, and am adding a
BUILT_SOURCES directive in a separate commit.

~Neels


On Mon, Dec 21, 2015 at 08:44:35PM +0100, Alexander Huemer wrote:
> ---
>  src/Makefile.am | 9 ---------
>  1 file changed, 9 deletions(-)
> 
> diff --git a/src/Makefile.am b/src/Makefile.am
> index 73b3987..48c861d 100644
> --- a/src/Makefile.am
> +++ b/src/Makefile.am
> @@ -11,20 +11,11 @@ bin_PROGRAMS = hnbgw
>  hnbgw_SOURCES = hnbap_encoder.c hnbap_decoder.c rua_encoder.c rua_decoder.c ranap_common.c rua_common.c hnbap_common.c iu_helpers.c asn1helpers.c hnbgw.c hnbgw_hnbap.c hnbgw_rua.c hnbgw_ranap.c ranap_decoder.c ranap_encoder.c ranap_msg_factory.c
>  hnbgw_LDADD = $(OSMOCORE_LIBS) $(OSMOVTY_LIBS) $(OSMOGSM_LIBS) $(ASN1C_LIBS) $(COMMON_LDADD) hnbap/libosmo-asn1-hnbap.a rua/libosmo-asn1-rua.a ranap/libosmo-asn1-ranap.a
>  
> -ranap_ies_defs.h: ranap_encoder.c
> -ranap_decoder.c: ranap_encoder.c
> -
> -rua_ies_defs.h: rua_encoder.c
> -rua_decoder.c: rua_encoder.c
> -
>  hnbap_encoder.c hnbap_decoder.c hnbap_ies_defs.h: $(ASN1_ROOT)/hnbap/HNBAP-PDU-Contents.asn
> -hnbap_encoder.c : $(ASN1_ROOT)/hnbap/HNBAP-PDU-Contents.asn
>  	$(ASN1TOSTRUCT) -f $<
>  
>  rua_encoder.c rua_decoder.c rua_ies_defs.h: $(ASN1_ROOT)/rua/RUA-PDU-Contents.asn
> -rua_encoder.c : $(ASN1_ROOT)/rua/RUA-PDU-Contents.asn
>  	$(ASN1TOSTRUCT) -p RUA_ -f $<
>  
>  ranap_encoder.c rua_decoder.c rua_ies_defs.h : $(ASN1_ROOT)/ranap/RANAP-PDU-Contents.asn
> -ranap_encoder.c : $(ASN1_ROOT)/ranap/RANAP-PDU-Contents.asn
>  	$(ASN1TOSTRUCT) -p RANAP_ -f $<
> -- 
> 2.6.2
>

Hi Neels.

Yes, my fix did only work for parallel make jobs, it fails with -j1, I should
have checked that.
Unfortunately the current HEAD does not build for me either. Make output (-j2):

> Making all in src
> make[1]: Entering directory '/home/blackbit/src/telco/osmo/osmo-iuh/src'
> Makefile:732: warning: overriding recipe for target 'rua_decoder.c'
> Makefile:729: warning: ignoring old recipe for target 'rua_decoder.c'
> Makefile:732: warning: overriding recipe for target 'rua_ies_defs.h'
> Makefile:729: warning: ignoring old recipe for target 'rua_ies_defs.h'
> ../asn1//utils/asn1tostruct.py -f ../asn1//hnbap/HNBAP-PDU-Contents.asn
> ../asn1//utils/asn1tostruct.py -f ../asn1//hnbap/HNBAP-PDU-Contents.asn
> Didn't find any information element for message: PrivateMessage-IEs
> Didn't find any information element for message: PrivateMessage-IEs
> ../asn1//utils/asn1tostruct.py -p RANAP_ -f ../asn1//ranap/RANAP-PDU-Contents.asn
> ../asn1//utils/asn1tostruct.py -p RUA_ -f ../asn1//rua/RUA-PDU-Contents.asn
> make[1]: *** No rule to make target 'ranap_decoder.c', needed by 'all'.  Stop.
> make[1]: *** Waiting for unfinished jobs....
> Didn't find any information element for message: PrivateMessage-IEs
> Didn't find any information element for message: RelocationDetectIEs
> Didn't find any information element for message: RelocationCompleteIEs
> Didn't find any information element for message: RAB-SetupOrModifyItem-IEs
> Didn't find any information element for message: PrivateMessage-IEs
> Didn't find any information element for message: DirectTransferInformationItemIEs-RANAP-RelocInf
> Didn't find any information element for message: SRVCC-CSKeysRequestIEs
> Didn't find any information element for message: UeRadioCapabilityMatchRequestIEs
> make[1]: Leaving directory '/home/blackbit/src/telco/osmo/osmo-iuh/src'
> Makefile:345: recipe for target 'all-recursive' failed
> make: *** [all-recursive] Error 1

When looking at src/Makefile.am again I noticed something that I think is a
copy/paste mistake. When I correct it with the following patch the build works
for me with -j[1234].
Maybe that's the last patch needed for this issue, this really should not be
so difficult.

On Tue, Dec 22, 2015 at 02:59:06PM +0100, Alexander Huemer wrote:
> Yes, my fix did only work for parallel make jobs, it fails with -j1, I should
> have checked that.
> Unfortunately the current HEAD does not build for me either. Make output (-j2):

There seem to be some odd situations where the build works coincidentally
when the order of dependencies fall into lucky places, which is probably
why I didn't get this last error...

> > make[1]: *** No rule to make target 'ranap_decoder.c', needed by 'all'.  Stop.
> > make[1]: *** Waiting for unfinished jobs....

> When looking at src/Makefile.am again I noticed something that I think is a
> copy/paste mistake.

[[[
-ranap_encoder.c rua_decoder.c rua_ies_defs.h: $(ASN1_ROOT)/ranap/RANAP-PDU-Contents.asn
+ranap_encoder.c ranap_decoder.c ranap_ies_defs.h: $(ASN1_ROOT)/ranap/RANAP-PDU-Contents.asn
]]]

wow, how did we miss that...
Thanks! Will commit.

> Maybe that's the last patch needed for this issue, this really should not be
> so difficult.

Hehe, indeed.

~Neels