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
