Bruce, > >> This sounds like something I've said before: Should recommended procedures > >> *not* trigger "this is obsolete" type messages? > > ... > My suggestion would be to consider any recommended action that triggers a > "this > is obsolete" message to be a bug. The fix might belong in the docs, it might > belong > in not construing something obsolete or it might be to internally suppress the > warning. Wherever the fix belongs, it is unlikely that the person stubbing > their toe > on it is going to have a best guess as to where it belongs.
OK, it sounds you're undecided. My opinion is that the 'posix-modules' script, like 'gnulib-tool', should ignore obsolete modules by default, and have an option --with-obsolete. > the create-testdir worked, but it did not produce a project that could be > rolled up and distributed. I see. Sorry for the misunderstanding. > I am tweaking the result with the following: > > 1. version.[ch] and basing it off of the first date found in > gnulib/ChangeLog :) Good. Additionally you should also include the version number as determined by 'git': ./build-aux/git-version-gen /dev/null | sed -e 's/-dirty/-modified/' > 2. replacing libgnu.a with libposix.la You can use the gnulib-tool option --lib=libposix for this purpose. > 3. installing all the headers (see Makefile.am edits below) Yes, this is necessary. > 4. fixing AC_INIT() in configure.ac Yup. > 5. removing libtool conditionality -- making it required I don't see where you pass the option --libtool to gnulib-tool. > I'm not done yet, so there may be more. I'm doing it all with a single file > -- > a shell script that does everything. I note that your script requires bash-4.x (I get a syntax error with bash-3.2.39) and libtool-2.x in the PATH (I get an automake error "required file `build-aux/ltmain.sh' not found" otherwise). > It presumes itself to be living in a subdirectory within gnulib. It works also anywhere, assuming that gnulib-tool can be found in PATH. Bruno
