Bug 57170

Summary:	header file from ui file not built automatically
Product:	[Applications] kdevelop	Reporter:	Holger Schröder <holger-kde>
Component:	Build tools: Automake	Assignee:	KDevelop Developers <kdevelop-devel>
Status:	RESOLVED NOT A BUG
Severity:	normal
Priority:	NOR
Version:	unspecified
Target Milestone:	---
Platform:	Gentoo Packages
OS:	Linux
Latest Commit:		Version Fixed In:
Attachments:	this is the output of the message window from the make process, when it fails for the first time this is the output from the second run

Description Holger Schröder 2003-04-12 23:47:58 UTC

Version:            (using KDE KDE 3.1.1)
Installed from:    Gentoo Packages

Hi,

i have the following problem: i have created a project with gideon(actual cvs version from this week), and for some reason, after i make distclean and after that automake, configure, make, the make process forgets to create a .h file from a .ui file.

my project is rpclient.
the file names for me are:

rpclient/src/rphauptmenubase.ui (the ui file)

as i am subclassing from this class, i need the three files:
rphauptmenubase.cpp
rphauptmenubase.h
rphauptmenubase.moc

when i check if these files exist, they do exist, but it seems as if they are built too late in the building process, as the rphauptmenubase.h file does not exist, when it is needed by rphauptmenu.h from rpclientview.cpp.

when i run the build process a second time by pressing F8, it finishes successful, as the file exists already, when it is needed this time.

i will attach the first and the second output of the message window, so that you can see, what exactly is going on.

thanks, Holger

Comment 1 Holger Schröder 2003-04-12 23:51:36 UTC

Created attachment 1351 [details]
this is the output of the message window from the make process, when it fails for the first time

Comment 2 Holger Schröder 2003-04-12 23:53:39 UTC

Created attachment 1352 [details]
this is the output from the second run

as you can see, the second run finishes successfully, as the needed .h file is
created later in the first run.

Comment 3 Jens Dagerbo 2003-07-14 19:53:14 UTC

Yeah, this happens. :( 
 
Can this be fixed in autoproject, or do we just point the finger at the build system?

Comment 4 Alexander Dymo 2003-07-28 00:37:36 UTC

I see no way to fix it in autoproject - it's a build system bug. Closing.