On Mon, Mar 10, 2014 at 10:28:51PM +0100, Lukas Slebodnik wrote: > On (10/03/14 14:31), Dmitri Pal wrote: > >On 03/10/2014 02:30 AM, Lukas Slebodnik wrote: > >>On (08/03/14 02:00), Dmitri Pal wrote: > >>>On 03/08/2014 01:40 AM, Dmitri Pal wrote: > >>>>On 03/07/2014 12:00 PM, Jakub Hrozek wrote: > >>>>>On Fri, Mar 07, 2014 at 05:49:44PM +0100, Jakub Hrozek wrote: > >>>>>>On Fri, Mar 07, 2014 at 10:19:11AM -0500, Dmitri Pal wrote: > >>>>>>>On 03/07/2014 10:11 AM, Jan Engelhardt wrote: > >>>>>>>>On Friday 2014-03-07 15:15, Lukas Slebodnik wrote: > >>>>>>>>>>>>>>attached patch addresses ticket #2193 > >>>>>>>>>Jan, > >>>>>>>>>Do you have any other comments to the patch from previous mail? > >>>>>>>>No further comments at this time. Please, just get it > >>>>>>>>included already :} > >>>>>>>>_______________________________________________ > >>>>>>>>sssd-devel mailing list > >>>>>>>>sssd-devel@lists.fedorahosted.org > >>>>>>>>https://lists.fedorahosted.org/mailman/listinfo/sssd-devel > >>>>>>>I am preparing a new patch for ini and it will add two new entry > >>>>>>>points but I can't finish the work until your patch is pushed. > >>>>>>ACK from me. make, make check, make distcheck and make rpms work fine. > >>>>>> > >>>>>>SSSD also seems to be working fine after I upgraded ding-libs > >>>>>>to the new > >>>>>>RPMs. > >>>>>Pushed to ding-libs master. > >>>>>_______________________________________________ > >>>>>sssd-devel mailing list > >>>>>sssd-devel@lists.fedorahosted.org > >>>>>https://lists.fedorahosted.org/mailman/listinfo/sssd-devel > >>>> > >>>>This push broke my deb builds on RHEL6: > >>>s/deb/dev > >>> > >>>Also removing EXTRA_ prefix seems to fix the issue. > >>>>[dpal@dpal ding-libs (master)]$ autoreconf -if > >>>>libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `build'. > >>>>libtoolize: copying file `build/ltmain.sh' > >>>>libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'. > >>>>libtoolize: copying file `m4/libtool.m4' > >>>>libtoolize: copying file `m4/ltoptions.m4' > >>>>libtoolize: copying file `m4/ltsugar.m4' > >>>>libtoolize: copying file `m4/ltversion.m4' > >>>>libtoolize: copying file `m4/lt~obsolete.m4' > >>>>Makefile.am:259: variable `EXTRA_libini_config_la_DEPENDENCIES' is > >>>>defined but no program or > >>>>Makefile.am:259: library has `EXTRA_libini_config_la' as canonical > >>>>name (possible typo) > >>>>autoreconf: automake failed with exit status: 1 > >>>> > >>>> > >>The EXTRA_*_DEPENDENCIES variable is useful for cases where you merely want > >>to augment the automake-generated _DEPENDENCIES variable rather than > >>replacing it. > >>http://www.gnu.org/software/automake/manual/html_node/Program-and-Library-Variables.html > >> > >>It is a syntax warning in automake< 1.11.3 and syntax warnings > >>are enabled by default. > >>http://lists.gnu.org/archive/html/automake-patches/2010-10/msg00008.html > >> > >>Makefile.am:259: variable `EXTRA_libini_config_la_DEPENDENCIES' is > >> defined but no program or library has `EXTRA_libini_config_la' > >> as canonical name (possible typo) > >>autoreconf: automake failed with exit status: 1 > >> > >>It would be better don't treat warnings as errors in automake. > >> > >>The only negative of this solution is that library libini_conf will not be > >>recompiled with older version of automake if files listed in > >>EXTRA_*_DEPENDENCIES are changed. It is better to see warnings than override > >>automatically generated dependencies calculated by automake with > >>syntax: *_DEPENDENCIES > >> > >>Patch is attached. > >> > >>LS > If _DEPENDENCIES is not supplied, it is computed by Automake. > The automatically-assigned value is the contents of _LDADD or _LIBADD, > with most configure substitutions, -l, -L, -dlopen and -dlpreopen options > removed. > > _DEPENDENCIES will overrride aotomatically generated dependencies because > automake knows that author did it intentionaly and author has a good reason > for > this. > > The EXTRA_*_DEPENDENCIES variable may be useful for cases where you merely > want > to augment the automake-generated _DEPENDENCIES variable rather than replacing > it. > > >But you use EXTRA prefix only with libini_config and not with other > >libraries generated by this package. What is the difference? > libpath_utils, libdhash, libcollection, libref_array, libbasicobjects are > simple libraries and do not depend on other library. It is possible to use > *_DEPENDENCIES because nothing will be overridden. EXTRA_*_DEPENDENCIES could > be used as well. > > libini_config depends on the other libraries. > > libini_config_la_LIBADD = \ > libcollection.la \ > libpath_utils.la \ > libref_array.la \ > libbasicobjects.la > > 1st version: > libini_config_la_DEPENDENCIES = ini/libini_config.sym > > The previous line will replace automake-generated dependencies. If > libcollection is changed libini_config will not be rebuilt. > Yes, you can still use: make clean && make to workaround this problem. > It can cause weird behaviour if you forget to clean project. > > 2nd version: > EXTRA_libini_config_la_DEPENDENCIES = ini/libini_config.sym > > It works as expected with newer automake. > > With automake < 1.11.3, EXTRA_*_DEPENDENCIES is ignored (unknown syntax) > Automake-generated dependencies are not replaced. There is drawback > libini_config will not be rebuilt if file ini/libini_config.sym is changed. > Again, you can still use: make clean && make to workaround this problem. > libini_config.sym will be usually changed together with other source codes. > So, it is not very likely you will hit this situation. > > > >I would have understood if all libraries used EXTRA prefix but it is > >not the case. Or it is a bug? > > > >Package that I have is 1.11.1. There is no other version available. > > > >What is the recommendation with this issue? > > > > I was thinking about this issue and I can see yet another solution > (workaround) > which should work with older verions of automake. > > 3rd version: > We can add all dependencies manually because ding-libs doesn't have > complicated > dependencies > > libini_config_la_DEPENDENCIES = \ > ini/libini_config.sym \ > libcollection.la \ > libpath_utils.la \ > libref_array.la \ > libbasicobjects.la > > or shorter version: > libini_config_la_DEPENDENCIES = \ > ini/libini_config.sym \ > $(libini_config_la_LIBADD) > > > I can see two options: > 2nd version and do not treat automake warnings as errors > 3rd version (workaround) > > LS > > BTW: automake warnings EXTRA_*_DEPENDENCIES are also in sssd. > But each sssd developer use at least fedora 17. > We can ignore this warning on el6 build.
I'm sorry, I forgot about this patch and didn't come back until I was checking stale threads in patchwork today.. I would prefer to ignore automake warnings. Given the wide range of host OS we support ranging from RHEL-6 to latest Fedora we're going to continue running into incompatibilities and warninigs. I would prefer to treat them as non-fatal if possible. Do you see some downside to this? Do you anticipate that ignoring some warnigns might cause a wrong build? _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
