[Freeipa-devel] [freeipa PR#171][comment] Build system cleanup phase 2
URL: https://github.com/freeipa/freeipa/pull/171 Title: #171: Build system cleanup phase 2 lslebodn commented: """ On (20/10/16 10:29), Petr Špaček wrote: >@lslebodn I'm really trying to explain this but I'm still not able to get the >point across. >> My concerns are related purely to C-code. > >Please understand that IPA client consists of components in C as well from >components in Python, and also non-programatic components like translation >machinery etc. > Correct me If I am wrong. The configure script is and will be used just for detection of build dependencies for C-code. So here I cannot see a conflict with my proposal. >We certainly can create m4 include maze I cannot see a reason why it would be a maze Detection of client build dependencies will be done in main configure.ac Detection of server dependencies would be done in `daemons/configure.ac` `./ipatests/man/configure.ac` and `./install/configure.ac` does not have any C-related dependencies and `./asn1/configure.ac` is required by client code. IMHO ans1c/ can be moved to client/asn1c/ (but that's offtopic) There would not be much includes as I showed in POC >and force maintainer to always use `grep` before he finds particular part in >the build system. maintainers do not use grep for finding build dependencies. The most common use case is just to run configure script and wait for reported errors. pkg-config returns nice error messages. And then add new build dependency. However, C related code is not changed very often and even more C-related dependencies are added much less often. But if new depenendecy will be added to server part then it will be much simpler to review whether build dependency is added to the right section if server dependencies will be in separate file. >Unfortunatlly, even the m4 maze will not solve the problem that client-only >build of C binaries simply do not constitute working IPA client. >Integration with other Python components is necessary to get the client to >work. > Totally agree. But python components is not related to checking of build time dependencies for C-code. It should be solved in different PR IMHO, this PR should not complicate client-only build just for C-binaries. >The end goal is to fold all of hand-made Makefile and SPEC file scripts to the >build system, so in the end, it should help with porting to other arches - >there will be just one place where changes need to be done, instead of three. > Agree, but here I cannot see any conflict with my proposal. >I hope that it clears up why it is not useful to insist on keeping current >pieces as they were before. The design document was sent to freeipa-devel >mailing list in this thread: >https://www.redhat.com/archives/freeipa-devel/2016-October/msg00134.html >Please discuss conceptual questions on the mailing list so we can get >attention of other FreeIPA developers and avoid need to point people one by >one to this PR. > I read the desing page and there is mentioned that autotools will be used for C-part as an implementation and configure script should have the option --enable-server which default yes. I could not find any contradiction between my proposal and desing page. LS """ See the full comment at https://github.com/freeipa/freeipa/pull/171#issuecomment-256120734 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [freeipa PR#171][comment] Build system cleanup phase 2
URL: https://github.com/freeipa/freeipa/pull/171 Title: #171: Build system cleanup phase 2 dkupka commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/329f080e6ac832ffd568e79ebca9907771f8ad61 https://fedorahosted.org/freeipa/changeset/41da8732051c193166fa69cd9bc1152d39ad8720 https://fedorahosted.org/freeipa/changeset/25dab77301f9e0289b94b0a672aed5067384c8ce https://fedorahosted.org/freeipa/changeset/b0cb6afa2308b9d96456f0355771ecbef0ca7263 https://fedorahosted.org/freeipa/changeset/6e1d777d2878de1e90e1dab4949075d31ffb0d52 https://fedorahosted.org/freeipa/changeset/5e028b59bcd3c485cc034f491a0171f26b03ce3a https://fedorahosted.org/freeipa/changeset/927ddcb95aeb5c9bcc0cb08c5f08cecdccd0acb8 https://fedorahosted.org/freeipa/changeset/0d37619db41abddabdd313f036f453821f438c8a https://fedorahosted.org/freeipa/changeset/881ab4edffa5e9c6c8bd8fb9762e04d776c4a573 https://fedorahosted.org/freeipa/changeset/0d7d6f3904287bb4903ffaa9d8c61e7593ae76d6 https://fedorahosted.org/freeipa/changeset/1f1648691de6687e748c5b8267f43cf196bd7cc9 https://fedorahosted.org/freeipa/changeset/fd3176a72951a2baece36620341991feb94b230a https://fedorahosted.org/freeipa/changeset/b12da59a6cde3580f97e4ceb7303bc85857faf4d https://fedorahosted.org/freeipa/changeset/1e0143c159134337a00a91d4ae64e614f72da62e https://fedorahosted.org/freeipa/changeset/8acb1f37f581e92a56951c069c990c77e83f3c42 https://fedorahosted.org/freeipa/changeset/c8be979b3263723a9ab7b3c71efbe85b42d981e9 https://fedorahosted.org/freeipa/changeset/1a4f287931edf0f3a76e97875f4af622716475af https://fedorahosted.org/freeipa/changeset/38628e46f05bde5ccc0fbb997f79364860713b48 https://fedorahosted.org/freeipa/changeset/f25c0cb0c5f309944904fd32e781c27ae7e45a62 https://fedorahosted.org/freeipa/changeset/c954d0e1ba2a9ba8e8da679bc7246788d086d976 https://fedorahosted.org/freeipa/changeset/c70a2873f8a4447f8b38ad7b8468fc78c91bbb63 https://fedorahosted.org/freeipa/changeset/3e79d8ad4aef1f62372a2169699df345348ba3e9 """ See the full comment at https://github.com/freeipa/freeipa/pull/171#issuecomment-255715699 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [freeipa PR#171][comment] Build system cleanup phase 2
URL: https://github.com/freeipa/freeipa/pull/171 Title: #171: Build system cleanup phase 2 pspacek commented: """ Re-adding ACK which was removed while we were "resolving" our disagreement with Lukas. """ See the full comment at https://github.com/freeipa/freeipa/pull/171#issuecomment-255408029 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [freeipa PR#171][comment] Build system cleanup phase 2
URL: https://github.com/freeipa/freeipa/pull/171 Title: #171: Build system cleanup phase 2 lslebodn commented: """ We (lslebodn and pspacek) agree that we disagree about maintainability of client_only in one monolithic configure.ac. But we agreed that the refactoring of build system[1] is more important. I will close my eyes and you can push the patch-set. :-) [1] http://www.freeipa.org/page/V4/Build_system_refactoring """ See the full comment at https://github.com/freeipa/freeipa/pull/171#issuecomment-255404139 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [freeipa PR#171][comment] Build system cleanup phase 2
URL: https://github.com/freeipa/freeipa/pull/171 Title: #171: Build system cleanup phase 2 lslebodn commented: """ On (21/10/16 00:41), Petr Špaček wrote: >> Correct me If I am wrong. The configure script is and will be used >just for detection of build dependencies for C-code. > >Maybe this is why we do not understand each other. Autotools will orchestrate >the complete build including configuration of Python (and other) components. >This is what I meant by `Use autotools suite to orchestrate the build on the >top-level` in the design document. If it is confusing I'm happy to improve it, >just tell me what you want to see there. > I cannot see a problem here. Design page just say that you will be able to optionally build and install python2 and/or python3. And setuptools instead of distutils will manage that part. I cannot see any conflict with detecting build time dependencies for C-code with enabled server and without enabled server (client_only) >This PR starts to use configure to create symlinks in ipaplatform Python >module and more things are comming. If you look at >http://www.freeipa.org/page/V4/Build_system_refactoring#Configuration you will >see that configure is going contain switches for Python components as well as >for Javascript components. I.e. there is nothing like C-only configure >anymore. > Design page says something else. `./configure --without-python2 --without-python3 --without-pylint --without-jslint` . But I do not care about these options. My intention is to have a simple way how to implement "--enable-server/--disable-server". Merging everything to the one big configure script will not simplify it. It will just complicate it. And the purpose of refactoring is to make things simpler and easily maintainable. """ See the full comment at https://github.com/freeipa/freeipa/pull/171#issuecomment-255320295 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [freeipa PR#171][comment] Build system cleanup phase 2
URL: https://github.com/freeipa/freeipa/pull/171 Title: #171: Build system cleanup phase 2 pspacek commented: """ > Correct me If I am wrong. The configure script is and will be used just for detection of build dependencies for C-code. Maybe this is why we do not understand each other. Autotools will orchestrate the complete build including configuration of Python (and other) components. This is what I meant by `Use autotools suite to orchestrate the build on the top-level` in the design document. If it is confusing I'm happy to improve it, just tell me what you want to see there. This PR starts to use configure to create symlinks in ipaplatform Python module and more things are comming. If you look at http://www.freeipa.org/page/V4/Build_system_refactoring#Configuration you will see that configure is going contain switches for Python components as well as for Javascript components. I.e. there is nothing like C-only configure anymore. I hope it clears the intent. """ See the full comment at https://github.com/freeipa/freeipa/pull/171#issuecomment-255315466 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [freeipa PR#171][comment] Build system cleanup phase 2
URL: https://github.com/freeipa/freeipa/pull/171 Title: #171: Build system cleanup phase 2 lslebodn commented: """ On (20/10/16 10:29), Petr Špaček wrote: >@lslebodn I'm really trying to explain this but I'm still not able to get the >point across. >> My concerns are related purely to C-code. > >Please understand that IPA client consists of components in C as well from >components in Python, and also non-programatic components like translation >machinery etc. Correct me If I am wrong. The configure script is and will be used just for detection of build dependencies for C-code. So here I cannot see a conflict with my proposal. >We certainly can create m4 include maze I cannot see a reason why it would be a maze Detection of client build dependencies will be done in main configure.ac Detection of server dependencies would be done in `daemons/configure.ac` `./ipatests/man/configure.ac` and `./install/configure.ac` does not have any C-related dependencies and `./asn1/configure.ac` is required by client code. IMHO ans1c/ can be moved to client/asn1c/ (but that's offtopic) There would not be much includes as I showed in POC >and force maintainer to always use `grep` before he finds particular part in >the build system. maintainers do not use grep for finding build dependencies. The most common use case is just to run configure script and wait for reported errors. pkg-config returns nice error messages. And then add new build dependency. However, C related code is not changed very often and even more C-related dependencies are added much less often. But if new depenendecy will be added to server part then it will be much simpler to review whether build dependency is added to the right section if server dependencies will be in separate file. >Unfortunatlly, even the m4 maze will not solve the problem that client-only >build of C binaries simply do not constitute working IPA client. >Integration with other Python components is necessary to get the client to >work. Totally agree. But python components is not related to checking of build time dependencies for C-code. It should be solved in different PR IMHO, this PR should not complicate client-only build just for C-binaries. >The end goal is to fold all of hand-made Makefile and SPEC file scripts to the >build system, so in the end, it should help with porting to other arches - >there will be just one place +where changes need to be done, instead of three. Agree, but here I cannot see any conflict with my proposal. >I hope that it clears up why it is not useful to insist on keeping current >pieces as they were before. The design document was sent to freeipa-devel >mailing list in this thread: >https://www.redhat.com/archives/freeipa-devel/2016-October/msg00134.html >Please discuss conceptual questions on the mailing list so we can get >attention of other FreeIPA developers and avoid need to point people one by >one to this PR. I read the desing page and there is mentioned that autotools will be used for C-part as an implementation and configure script should have the option --enable-server which default yes. I could not find any contradiction between my proposal and desing page. LS """ See the full comment at https://github.com/freeipa/freeipa/pull/171#issuecomment-255313933 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [freeipa PR#171][comment] Build system cleanup phase 2
URL: https://github.com/freeipa/freeipa/pull/171 Title: #171: Build system cleanup phase 2 lslebodn commented: """ On (20/10/16 10:29), Petr Špaček wrote: >@lslebodn I'm really trying to explain this but I'm still not able to get the >point across. >> My concerns are related purely to C-code. > >Please understand that IPA client consists of components in C as well from >components in Python, and also non-programatic components like translation >machinery etc. > Correct me If I am wrong. The configure script is and will be used just for detection of build dependencies for C-code. So here I cannot see a conflict with my proposal. >We certainly can create m4 include maze I cannot see a reason why it would be a maze Detection of client build dependencies will be done in main configure.ac Detection of server dependencies would be done in `daemons/configure.ac` `./ipatests/man/configure.ac` and `./install/configure.ac` does not have any C-related dependencies and `./asn1/configure.ac` is required by client code. IMHO ans1c/ can be moved to client/asn1c/ (but that's offtopic) There would not be much includes as I showed in POC >and force maintainer to always use `grep` before he finds particular part in >the build system. maintainers do not use grep for finding build dependencies. The most common use case is just to run configure script and wait for reported errors. pkg-config returns nice error messages. And then add new build dependency. However, C related code is not changed very often and even more C-related dependencies are added much less often. But if new depenendecy will be added to server part then it will be much simpler to review whether build dependency is added to the right section if server dependencies will be in separate file. >Unfortunatlly, even the m4 maze will not solve the problem that client-only >build of C binaries simply do not constitute working IPA client. >Integration with other Python components is necessary to get the client to >work. > Totally agree. But python components is not related to checking of build time dependencies for C-code. It should be solved in different PR IMHO, this PR should not complicate client-only build just for C-binaries. >The end goal is to fold all of hand-made Makefile and SPEC file scripts to the >build system, so in the end, it should help with porting to other arches - >there will be just one place +where changes need to be done, instead of three. > Agree, but here I cannot see any conflict with my proposal. >I hope that it clears up why it is not useful to insist on keeping current >pieces as they were before. The design document was sent to freeipa-devel >mailing list in this thread: >https://www.redhat.com/archives/freeipa-devel/2016-October/msg00134.html >Please discuss conceptual questions on the mailing list so we can get >attention of other FreeIPA developers and avoid need to point people one by >one to this PR. > I read the desing page and there is mentioned that autotools will be used for C-part as an implementation and configure script should have the option --enable-server which default yes. I could not find any contradiction between my proposal and desing page. LS """ See the full comment at https://github.com/freeipa/freeipa/pull/171#issuecomment-255313933 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [freeipa PR#171][comment] Build system cleanup phase 2
URL: https://github.com/freeipa/freeipa/pull/171 Title: #171: Build system cleanup phase 2 pspacek commented: """ This PR including additional patches on top have passed build + all XMLRPC tests in Jenkins: job/build_refactoring-build-f24build_refactoring/18/ Additional commits can be found on https://github.com/pspacek/freeipa/commits/pr159-rebase The test included everything up to e33e00bdc17dc164a1c143d8cba85f5df6de9d7e """ See the full comment at https://github.com/freeipa/freeipa/pull/171#issuecomment-255180087 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [freeipa PR#171][comment] Build system cleanup phase 2
URL: https://github.com/freeipa/freeipa/pull/171 Title: #171: Build system cleanup phase 2 pspacek commented: """ @lslebodn I'm really trying to explain this but I'm still not able to get the point across. > My concerns are related purely to C-code. Please understand that IPA client consists of components in C as well from components in Python, and also non-programatic components like translation machinery etc. We certainly can create m4 include maze and force maintainer to always use `grep` before he finds particular part in the build system. Unfortunatlly, even the m4 maze will not solve the problem that client-only build of C binaries simply do not constitute working IPA client. Integration with other Python components is necessary to get the client to work. The end goal is to fold all of hand-made Makefile and SPEC file scripts to the build system, so in the end, it should help with porting to other arches - there will be just one place where changes need to be done, instead of three. I hope that it clears up why it is not useful to insist on keeping current pieces as they were before. The design document was sent to freeipa-devel mailing list in this thread: https://www.redhat.com/archives/freeipa-devel/2016-October/msg00134.html Please discuss conceptual questions on the mailing list so we can get attention of other FreeIPA developers and avoid need to point people one by one to this PR. Thank you for understanding. """ See the full comment at https://github.com/freeipa/freeipa/pull/171#issuecomment-255172783 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [freeipa PR#171][comment] Build system cleanup phase 2
URL: https://github.com/freeipa/freeipa/pull/171 Title: #171: Build system cleanup phase 2 pspacek commented: """ This version replaces ipaplatform magic with symlinks generated by configure. It should work with jcholast's PR 159. """ See the full comment at https://github.com/freeipa/freeipa/pull/171#issuecomment-255116485 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [freeipa PR#171][comment] Build system cleanup phase 2
URL: https://github.com/freeipa/freeipa/pull/171
Title: #171: Build system cleanup phase 2
lslebodn commented:
"""
> 08:53 < pspacek> lslebodn: I would appreciate patch showing the nicer
> solution to me. I do not think it
> is that easy as you claim, especially when we count in that
> client_only build depends heavily on spec file, which is
> not usable in Debian at all, which makes
> client-only-purely-upstream-point completely moot.
Currently it is possible to build just a client part with following steps. Ant
it has nothing to do with downstream specfile
```
make version-update
cd client; ../autogen.sh --prefix=%{_usr} --sysconfdir=%{_sysconfdir}
--localstatedir=%{_localstatedir} --libdir=%{_libdir} --mandir=%{_mandir}; cd ..
make client-install
```
As you can see configure script is executed only in client sub-directory.
Here I am not interested in python part of client code.
My concerns are pure related to C-code.
But after merging everything to the one big configure script it would not be
possible
without patching a master.
And you also wanted to see some patches with nicer solution
here is a POC:
```
AC_ARG_WITH([server],
[AC_HELP_STRING([--with-server],
[Whether to build with server support [yes]]
)
],
[],
with_server=yes
)
if test x"$with_server" = xyes; then
AC_SUBST(HAVE_SERVER)
AC_DEFINE_UNQUOTED(HAVE_SERVER, 1, [Build with server support])
m4_include([./install/configure.ac.inc]]
m4_include([./daemons/configure.ac.inc]]
m4_include([./asn1/configure.acac.inc]]
fi
m4_include([./client/configure.ac])
AM_CONDITIONAL([BUILD_SERVER], [test x"$with_server" = xyes])
```
Or If you you can merge configure part into main configure script rather then
`m4_include([./client/configure.ac])`
"""
See the full comment at
https://github.com/freeipa/freeipa/pull/171#issuecomment-255108446
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [freeipa PR#171][comment] Build system cleanup phase 2
URL: https://github.com/freeipa/freeipa/pull/171
Title: #171: Build system cleanup phase 2
lslebodn commented:
"""
> 08:53 < pspacek> lslebodn: I would appreciate patch showing the nicer
> solution to me. I do not think it
> is that easy as you claim, especially when we count in that
> client_only build depends heavily on spec file, which is
> not usable in Debian at all, which makes
> client-only-purely-upstream-point completely moot.
Currently it is possible to build just a client part with following steps. Ant
it has nothing to do with downstream specfile
```
make version-update
cd client; ../autogen.sh --prefix=%{_usr} --sysconfdir=%{_sysconfdir}
--localstatedir=%{_localstatedir} --libdir=%{_libdir} --mandir=%{_mandir}; cd ..
make client-install
```
As you can see configure script is executed only in client sub-directory.
Here I am not interested in python part of client code.
My concerns are pure related to C-code.
But after merging everything to the one big configure script it would not be
possible
without patching a master.
And you also wanted to see some patches with nicer solution
here is a POC:
```
AC_ARG_WITH([server],
[AC_HELP_STRING([--with-server],
[Whether to build with server support [yes]]
)
],
[],
with_server=yes
)
if test x"$with_server" = xyes; then
AC_SUBST(HAVE_SERVER)
AC_DEFINE_UNQUOTED(HAVE_SERVER, 1, [Build with server support])
m4_include([./install/configure.ac.inc]]
m4_include([./daemons/configure.ac.inc]]
m4_include([./asn1/configure.acac.inc]]
fi
m4_include([./client/configure.ac])
AM_CONDITIONAL([BUILD_SERVER], [test x"$with_server" = xyes])
```
Or If you you can merge configure part into main configure script rather then
`m4_include([./client/configure.ac])`
"""
See the full comment at
https://github.com/freeipa/freeipa/pull/171#issuecomment-255108446
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [freeipa PR#171][comment] Build system cleanup phase 2
URL: https://github.com/freeipa/freeipa/pull/171
Title: #171: Build system cleanup phase 2
lslebodn commented:
"""
> 08:53 < pspacek> lslebodn: I would appreciate patch showing the nicer
> solution to me. I do not think it
> is that easy as you claim, especially when we count in that
> client_only build depends heavily on spec file, which is
> not usable in Debian at all, which makes
> client-only-purely-upstream-point completely moot.
Currently it is possible to build just a client part with following steps. Ant
it has nothing to do with downstream specfile
```
make version-update
cd client; ../autogen.sh --prefix=%{_usr} --sysconfdir=%{_sysconfdir}
--localstatedir=%{_localstatedir} --libdir=%{_libdir} --mandir=%{_mandir}; cd ..
make client-install
```
As you can see configure script is executed only in client sub-directory.
Here I am not interested in python part of client code.
My concerns are pure related to C-code.
But after merging everything to the one big configure script it would not be
possible
without patching a master.
And you also wanted to see some patches with nicer solution
here is a POC:
```
AC_ARG_WITH([server],
[AC_HELP_STRING([--with-server],
[Whether to build with server support [yes]]
)
],
[],
with_server=yes
)
if test x"$with_server" = xyes; then
AC_SUBST(HAVE_SERVER)
AC_DEFINE_UNQUOTED(HAVE_SERVER, 1, [Build with server support])
m4_include([./install/configure.ac.inc]]
m4_include([./daemons/configure.ac.inc]]
m4_include([./asn1/configure.acac.inc]]
fi
m4_include([./client/configure.ac])
AM_CONDITIONAL([BUILD_SERVER], [test x"$with_server" = xyes])
```
Or If you you can merge configure part into main configure script rather then
`m4_include([./client/configure.ac])`
"""
See the full comment at
https://github.com/freeipa/freeipa/pull/171#issuecomment-255108446
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [freeipa PR#171][comment] Build system cleanup phase 2
URL: https://github.com/freeipa/freeipa/pull/171 Title: #171: Build system cleanup phase 2 tiran commented: """ ACK make rpms is passing on my machine. """ See the full comment at https://github.com/freeipa/freeipa/pull/171#issuecomment-255099321 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [freeipa PR#171][comment] Build system cleanup phase 2
URL: https://github.com/freeipa/freeipa/pull/171 Title: #171: Build system cleanup phase 2 tiran commented: """ I agree with @lslebodn . It should be possible to build only the necessary bits and pieces for an IPA client. It should be rather simple to implement a ```--without-server``` ```AC_ARG_WITH()``` in another PR. Just move server-only ```PKG_CHECK_MODULES``` and ```AC_CONFIG_FILES()``` blocks into a ```if test "x$with_server" = "xyes"; then ... fi block. **To be clear**: I'm fine with this PR. client-only installation can be added in a later PR. Since it it easy to implement we can re-add it later without much trouble. """ See the full comment at https://github.com/freeipa/freeipa/pull/171#issuecomment-255093805 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [freeipa PR#171][comment] Build system cleanup phase 2
URL: https://github.com/freeipa/freeipa/pull/171 Title: #171: Build system cleanup phase 2 tiran commented: """ I agree with @lslebodn . It should be possible to build only the necessary bits and pieces for an IPA client. It should be rather simple to implement a ```--without-server``` ```AC_ARG_WITH()``` in another PR. Just move server-only ```PKG_CHECK_MODULES``` and ```AC_CONFIG_FILES()``` blocks into a ```if test "x$with_server" = "xyes"; then ... fi block. """ See the full comment at https://github.com/freeipa/freeipa/pull/171#issuecomment-255093805 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [freeipa PR#171][comment] Build system cleanup phase 2
URL: https://github.com/freeipa/freeipa/pull/171 Title: #171: Build system cleanup phase 2 lslebodn commented: """ > Please note that current client-only build is quite broken and requires heavy > machinery in downstream spec file so it is hard to speak about any reusage. That's the problem of ugly downstream spec file. This is a pure upstream discussion and how to make at least part of freeIPA more portable rather then closing doors for other platforms/distributions without systemd. There are still people on debian which does not use systemd and want to use sssd and ipa-client. The current patch-set would not create more portable client code. It would would just make it much harder and would require more downstream patches which is not very upstream friendly approach. @pspacek, it would be good if you could comment my proposal with including configure snippets from subdirectories. `m4_include` works like a magic and if conditions around them would make much nicer configure script. """ See the full comment at https://github.com/freeipa/freeipa/pull/171#issuecomment-255043715 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [freeipa PR#171][comment] Build system cleanup phase 2
URL: https://github.com/freeipa/freeipa/pull/171 Title: #171: Build system cleanup phase 2 pspacek commented: """ @lslebodn Please discuss this matter on freeipa-devel list to gethigher visibility. Please note that current client-only build is quite broken and requires heavy machinery in downstream spec file so it is hard to speak about any reusage. """ See the full comment at https://github.com/freeipa/freeipa/pull/171#issuecomment-255038213 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [freeipa PR#171][comment] Build system cleanup phase 2
URL: https://github.com/freeipa/freeipa/pull/171 Title: #171: Build system cleanup phase 2 lslebodn commented: """ My proposal would not require any reimplementation because it will reuse current solution. And I would like to know the reasons why upstream might consider to drop client_only feature. There are still distribution/platforms which does not have systemd which s required for server part. And decision to drop client-only feature would not increase portability of currently fedora based project. """ See the full comment at https://github.com/freeipa/freeipa/pull/171#issuecomment-255035073 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [freeipa PR#171][comment] Build system cleanup phase 2
URL: https://github.com/freeipa/freeipa/pull/171 Title: #171: Build system cleanup phase 2 pspacek commented: """ @lslebodn Decision if we need client_only build is still open. We may drop it so reimplementing it would be busy work. """ See the full comment at https://github.com/freeipa/freeipa/pull/171#issuecomment-255023841 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [freeipa PR#171][comment] Build system cleanup phase 2
URL: https://github.com/freeipa/freeipa/pull/171 Title: #171: Build system cleanup phase 2 lslebodn commented: """ BTW I am really interested in how do you plan to implement client only build. IMHO it would be much simpler include reduced version of daemon/configure.ac (+others) into top level configure.ac rather then creating if/else branches in huge long unified configured.ac """ See the full comment at https://github.com/freeipa/freeipa/pull/171#issuecomment-254843953 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [freeipa PR#171][comment] Build system cleanup phase 2
URL: https://github.com/freeipa/freeipa/pull/171 Title: #171: Build system cleanup phase 2 lslebodn commented: """ I see you need to increase patch_count and not to have proper review """ See the full comment at https://github.com/freeipa/freeipa/pull/171#issuecomment-254820687 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [freeipa PR#171][comment] Build system cleanup phase 2
URL: https://github.com/freeipa/freeipa/pull/171 Title: #171: Build system cleanup phase 2 mbasti-rh commented: """ I see just bikeshading here, on IRC Petr1 agreed that this should be pushed and incrementally upgraded according our needs """ See the full comment at https://github.com/freeipa/freeipa/pull/171#issuecomment-254809761 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [freeipa PR#171][comment] Build system cleanup phase 2
URL: https://github.com/freeipa/freeipa/pull/171 Title: #171: Build system cleanup phase 2 pspacek commented: """ @lslebodn If you read the pull request description you will notice that client-only build will be solved later on. """ See the full comment at https://github.com/freeipa/freeipa/pull/171#issuecomment-254803410 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [freeipa PR#171][comment] Build system cleanup phase 2
URL: https://github.com/freeipa/freeipa/pull/171 Title: #171: Build system cleanup phase 2 lslebodn commented: """ BTW. previously it was possible to build just a client code. But after these changes configure will require to have installed even daemon dependencies If someone decide to build just a client. Is there a reason why there is not a configure time option for such use-case. It would skip detections of build requirements for daemon part. """ See the full comment at https://github.com/freeipa/freeipa/pull/171#issuecomment-254802847 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [freeipa PR#171][comment] Build system cleanup phase 2
URL: https://github.com/freeipa/freeipa/pull/171 Title: #171: Build system cleanup phase 2 pspacek commented: """ I consider CURL topic to be just bikesheding. Ad POPT: RHEL is going to require explicit configuration as designed in http://www.freeipa.org/page/V4/Build_system_refactoring because you have to explicitly disable missing checks etc. anyway. At the same time you can provide correct POPT flags. If RHEL packager disagrees we can use some auto-magic but I would rather avoid it whenever possible. For reasons above, I think that upstream version should use pkgconfig as it is preferred way for library auto-detection. """ See the full comment at https://github.com/freeipa/freeipa/pull/171#issuecomment-254802857 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [freeipa PR#171][comment] Build system cleanup phase 2
URL: https://github.com/freeipa/freeipa/pull/171 Title: #171: Build system cleanup phase 2 lslebodn commented: """ and the explanation for changing curl is not appropriate. -1 """ See the full comment at https://github.com/freeipa/freeipa/pull/171#issuecomment-254800904 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [freeipa PR#171][comment] Build system cleanup phase 2
URL: https://github.com/freeipa/freeipa/pull/171 Title: #171: Build system cleanup phase 2 stlaz commented: """ +1 to push, the comments were added to outdated diffs so I thought them resolved. They are now. """ See the full comment at https://github.com/freeipa/freeipa/pull/171#issuecomment-254800566 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [freeipa PR#171][comment] Build system cleanup phase 2
URL: https://github.com/freeipa/freeipa/pull/171 Title: #171: Build system cleanup phase 2 lslebodn commented: """ I am sorry I still do not agree with popt change reducing 3lines to 1 is not huge simplification. And it does not work on rhel7.2 """ See the full comment at https://github.com/freeipa/freeipa/pull/171#issuecomment-254800570 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [freeipa PR#171][comment] Build system cleanup phase 2
URL: https://github.com/freeipa/freeipa/pull/171 Title: #171: Build system cleanup phase 2 pspacek commented: """ Justification is above, please push. """ See the full comment at https://github.com/freeipa/freeipa/pull/171#issuecomment-254800046 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [freeipa PR#171][comment] Build system cleanup phase 2
URL: https://github.com/freeipa/freeipa/pull/171 Title: #171: Build system cleanup phase 2 lslebodn commented: """ -ACK, my comments has not been addressed yet. """ See the full comment at https://github.com/freeipa/freeipa/pull/171#issuecomment-254797969 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [freeipa PR#171][comment] Build system cleanup phase 2
URL: https://github.com/freeipa/freeipa/pull/171 Title: #171: Build system cleanup phase 2 stlaz commented: """ ACK, works for me. """ See the full comment at https://github.com/freeipa/freeipa/pull/171#issuecomment-254788258 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [freeipa PR#171][comment] Build system cleanup phase 2
URL: https://github.com/freeipa/freeipa/pull/171 Title: #171: Build system cleanup phase 2 lslebodn commented: """ ACK to Build: modernize SASL library detection Build: modernize XMLRPC-client library detection Build: cleanup INI library detection It would be good to push them if you do not want to wait for review of other patches. """ See the full comment at https://github.com/freeipa/freeipa/pull/171#issuecomment-254777931 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [freeipa PR#171][comment] Build system cleanup phase 2
URL: https://github.com/freeipa/freeipa/pull/171 Title: #171: Build system cleanup phase 2 pspacek commented: """ This version fixes minor problems in error reporing and should have no other visible effect. """ See the full comment at https://github.com/freeipa/freeipa/pull/171#issuecomment-254550722 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
