[Lsb-infrastructure] [Bug 2891] mklibspec is not flexible enough when looking for interface pages

bugzilla-daemon at linux-foundation.org bugzilla-daemon at linux-foundation.org
Fri Jan 29 04:11:15 PST 2010


http://bugs.linuxbase.org/show_bug.cgi?id=2891

--- Comment #2 from Denis Silakov <silakov at ispras.ru> 2010-01-29 04:11:14 PST ---
Created an attachment (id=1647)
 --> (http://bugs.linuxbase.org/attachment.cgi?id=1647)
Possible LSB/AMD64/intro/makefile improvement

Well, to avoid *m4 copying we can modify appropriate makefiles. The attached is
a possible variant of LSB/AMD64/intro/makefile - under the '.m4.sgml' rule, it
first looks for appropriate *m4 file in the current directory, and if nothing
is found, then file is taken from appropriate generic subfolder.

Not sure if this make things much more clear, but it does allow to avoid
copying.

However, there is a disadvantage - if we we take *m4 file from the generic
folder, appropriate *sgml will be always regenerated, even if its current copy
is fresh enough - the thing is that 'make' will try to check timestamp of *m4
file in the current directory. In addition, we still have to explicitly define
'intro.m4' and 'cxxintro.m4' targets (though they are now empty).

An alternative way is to replace '.m4.sgml' with single '%.sgml' pattern, but
its disadvantage is also clear - we have sgml files that are generated from the
database, so if someone will invoke 'make' in the totally clean directory
without 'make gensrc', he will be definitely confused by messages like "m4:
cannot open `../../generic/intro/standards.m4': No such file or directory",
because 'make' will try to create all sgmls using m4.

And surely, we can explicitly say that sgmls depend on appropriate
../../generic/.../*m4, but this will leave us without possibility to use
arch-specific files, if necessary...

Uh, makefiles are definitely more tricky then mklibspec script...

-- 
Configure bugmail: http://bugs.linuxbase.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.


More information about the lsb-infrastructure mailing list