Bug 471703 - RFE: new "make" target that does not use 98-100% CPU
RFE: new "make" target that does not use 98-100% CPU
Product: Publican
Classification: Community
Component: publican (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Ruediger Landmann
Joshua Wulf
: Documentation
Depends On:
  Show dependency treegraph
Reported: 2008-11-14 21:07 EST by Murray McAllister
Modified: 2016-06-17 17:12 EDT (History)
7 users (show)

See Also:
Fixed In Version: 1.0
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-11-25 23:59:45 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Murray McAllister 2008-11-14 21:07:18 EST
I would like a new "make" targeted that does not use between 98% and 100% CPU.

Version-Release number of selected component (if applicable):
* publican-0.38-0

Additional info:
After thinking this over, I decided that it does not have to be a new "make" targeted - feel free to change existing targets to use less CPU. "make test" does not count.
Comment 1 Murray McAllister 2008-11-14 21:09:34 EST
* "...does not have to be a new "make" target - ..."
Comment 2 Jeff Fearn 2008-11-16 23:28:00 EST
Doing anything about the performance really requires the make files to be rewritten in a proper programming language. This would take about 3 weeks to complete.

One side affect of doing this would be that each books make file would need to be converted to a suitable configuration file. e.g. a conf, ini or xml file.

Doing this would make the creation of a GUI, or integrating the build in an editing tool, easier.
Comment 3 Christopher Curran 2009-02-26 01:04:25 EST
Why write a net configuration file when you can just parse the existing make file in new ways. Just write publican.pl which looks the same as make and has similar functionality to the existing make system.

For example, the present system:
make html-single-en-US

Hypothetical new system:
publican html-single-en-US

And spit out errors like:
"You're not in a publican books directory, you dolt!"
"I can't find a Makefile"
Comment 4 Douglas Silas 2009-03-01 20:49:34 EST
Or, similarly...

prepForPublican = do
	wd ← liftIO $ getWorkingDirectory
	conts ← liftIO $ getDirectoryContents wd >>= return ◦ filter (∉ [".", ".."])
	env ← ask
	state ← get
	if lit_Makefile ∉ conts
		then do
			outLine $ msgNoBuildFile wd
			retCode 1 fnNm
		else do
			mf ← parseMakefile `liftM` (liftIO $ readFile lit_Makefile)
			put state
				{ makefile = Just mf
				, docLocation = lookup "XML_LANG" mf
				, docName = (flip addExtension $ ".xml")
					`liftM` (lookup "DOCNAME" mf)}
			retCode 0 fnNm
	fnNm = "prepForPublican"
	msgNoBuildFile wd = docitErr ⧺ fnNm ⧺ ": "
		⧺ "a Makefile does not not exist in the current working directory: " ⧺ wd
Comment 5 Michael Hideo 2009-06-16 22:31:18 EDT
This is being addressed. Stay tuned until post docs.redhat.com rebase.
Comment 6 Jeff Fearn 2009-08-10 19:24:01 EDT
This should be fixed in the BETA.
Comment 7 Ruediger Landmann 2009-09-07 19:06:42 EDT
Fixed in 1.0

I built a simple book[1] with the following results:

Version 0.44 -- took 73 seconds and used between 60% and 70% CPU for most of that time, but used 92% CPU for the final stage of the build, once Saxon was called.

Version 1.0 -- took 3 seconds, and CPU shot up to a maximum of 40% momentarily (less than a second).
Comment 9 Fedora Update System 2009-11-17 21:19:45 EST
publican-1.2-0.fc12 has been submitted as an update for Fedora 12.
Comment 10 Fedora Update System 2009-11-20 00:18:58 EST
publican-1.2-0.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 11 Fedora Update System 2009-11-25 09:54:03 EST
publican-1.2-0.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.