All, I have been thinking about openrc's build system, and I'm thinking that we might want to use a configure script. Christian thinks that we should convert to autotools, but I am thinking that this situation is one of those where I'm not sure that the amount of gain we get by converting justifies the amount of work it would take to convert. However, I am open to using a configure script similar to the one Roy uses with dhcpcd. Mike and others, what are your thoughts?
i can do the conversion easy. that doesn't worry me. can you post the issues you think would be solved/simplified by moving to autotools ?
I think it would make it easier for us e.g. if we're going to require ERE (Extended Regular Expressions) support or other things. It should also fix the make check parallel bug :P And last but not least I guess it will be easier to maintain, less Makefiles and so on.
last i looked, parallel building worked fine i'm not sure init.d scripts would make any difference at all. you can't really test `sed` and say "if that supports ERE's, then when openrc gets merged into $ROOT, the `sed` there will also support ERE's". think cross-compiling and binpkg deployment.
Another disadvantage of converting to autotools is that since parts of release tarballs will become generated and not in the git repository, we will have to start hosting the release tarballs in someone's dev space. It will need to be a consistent place so that we aren't jumping around with different releases in different dev's spaces. Since we are not a gentoo only project, we will have to keep these tarballs in our dev spaces forever once they are made since they can't be duplicated by using make dist. I would rather see a configure script like what Roy has for dhcpcd. I do not want us using autotools. The things pointed out in comment #2 can be fixed without going that route.
Yes, we do have a number of Makefiles, and that can be reduced using conditionals in some of the Makefiles that we have. I can take a look at doing this.
(In reply to comment #3) > last i looked, parallel building worked fine > > i'm not sure init.d scripts would make any difference at all. you can't really > test `sed` and say "if that supports ERE's, then when openrc gets merged into > $ROOT, the `sed` there will also support ERE's". think cross-compiling and > binpkg deployment. I was more thinking about e.g. tests like: #include <stdio.h> #include <string.h> #include <errno.h> #include <regex.h> #define TEST_STR "foo" int main() { regex_t pattern; if (regcomp(&pattern, "(foo|bar)", REG_EXTENDED) != 0) { fprintf(stderr, "Error: regcomp(): %s\n", strerror(errno)); } if (regexec(&pattern, TEST_STR, 0, NULL, 0) != 0) { fprintf(stderr, "Error: OpenRC requires ERE (Extended Regular Expressions) support\n"); } regfree(&pattern); return 0; } (In reply to comment #4) > Another disadvantage of converting to autotools is that since parts of release > tarballs will become generated and not in the git repository, we will have to > start hosting the release tarballs in someone's dev space. It will need to be a > consistent place so that we aren't jumping around with different releases in > different dev's spaces. > > Since we are not a gentoo only project, we will have to keep these tarballs in > our dev spaces forever once they are made since they can't be duplicated by > using make dist. > > I would rather see a configure script like what Roy has for dhcpcd. I do not > want us using autotools. The things pointed out in comment #2 can be > fixed without going that route. We only need configure.ac and Makefile.am files. We can also add a autogen.sh or so. For git we can simply run "autoreconf -ifs". In the ebuild we could use eautoreconf. We can also host our tarballs on sf.net or so.
(In reply to comment #6) i don't find tarballs-out-of-git useful (as in i don't care either way). as for configure like dhcpcd, i would be against that. if we're going to write a configure script, then let's not half ass it. note that you can use autoconf without using automake. i still don't think any configure test on tools in $PATH are valid. using a hand written configure script or an autoconf makes no difference. (In reply to comment #6) couple of things: - testing the C library does not give you a complete indication of the syntax that the tools in $PATH support - you can't runtime test the C library when cross-compiling - you're still checking the code as found in the build system and not in the deployed system the fix for Bug 387355 is to stick to the POSIX spec
(In reply to comment #7) > (In reply to comment #6) > > i don't find tarballs-out-of-git useful (as in i don't care either way). The advantage of tarballs out of git is that they are identical every time they are generated, down to the checksums. This means in gentoo we do not have to worry about hosting them anywhere except the mirrors, and someone can create a tarball that is identical to ours by doing make dist from the git repository. Regarding hosting the tarballs on sf.net. I'm not really interested in hosting things there. I looked at the UI briefly, and I don't remember whether it is accessible or not. > as for configure like dhcpcd, i would be against that. if we're going to write > a configure script, then let's not half ass it. note that you can use autoconf > without using automake. I didn't think about using autoconf without automake, but, If we did this, it would mean that the configure script would write config.h and maybe an include file that the Makefiles would use, correct?
There will be a proper project hosting solution for Gentoo before the end of the year.
(In reply to comment #8) i understand the arguments for tarballs-out-of-git-tags. i just don't find them compelling enough to counteract the downsides (when applicable). i don't think hosting on any 3rd party system is necessary. Gentoo (even just dev space) should be fine until infra gets further along. there is no requirement that autoconf write out a config.h file, or anything for Makefile's to include. autoconf can do as little or as much as you want, and the filenames it (optionally) writes to can be controlled. it's all a simple matter of what you want to accomplish.
(In reply to comment #5) > Yes, we do have a number of Makefiles, and that can be reduced using > conditionals in some of the Makefiles that we have. > > I can take a look at doing this. This has been done in commit ecf7725. There were many operating system specific Makefile.* files in the tree, but these have been moved into the Makefiles which included them originally using Make's conditional processing.
so back to the original request, do we have a compelling reason to use autoconf ? or shall we punt this for now ?
also, i'm not sure your cleanup is really that much of an improvement. but i'll send out a patch to the openrc alias for that.
(In reply to comment #12) > so back to the original request, do we have a compelling reason to use autoconf > ? or shall we punt this for now ? I don't see a compelling reason to use autoconf, so I vote for punting the original request.
ince there have been no objections, I am closing this bug for now and changing the title to reflect that we cleaned up the Makefiles rather than writing a configure script.
