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(a)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(a)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?