Qt-interest Archive, March 2006
What exactly does DEPENDPATH do for me?
Message 1 in thread
The documentation says:
DEPENDPATH
This variable contains the list of all directories to look in to resolve
dependencies. This will be used when crawling through included files.
Well, that's nice to know. What does it mean?
Steven
--
[ signature omitted ]
Message 2 in thread
Hi,
Steven T. Hatton schrieb:
> The documentation says:
> DEPENDPATH
> This variable contains the list of all directories to look in to resolve
> dependencies. This will be used when crawling through included files.
when qmake creates a makefile it will consider header files found in the
DEPENDPATH for make dependencies. In many cases DEPENDPATH and
INCLUDEPATH will coincide, but there may be reasons for differences.
Have a nice day
Gert
--
[ signature omitted ]
Message 3 in thread
Quoting "Steven T. Hatton" <hattons@xxxxxxxxxxxxxxxxxx>:
> The documentation says:
> DEPENDPATH
> This variable contains the list of all directories to look in to resolve
> dependencies. This will be used when crawling through included files.
>
> Well, that's nice to know. What does it mean?
makefiles consist of targets, rules and dependencies (and variables and
extensions and other things, but let's forget them). And in short, the makefile
says
'if any of these dependencies change, then use this rule to build the target'
The DEPENDPATH controls the paths that are searched for dependencies. In
practice, this means included headers. As a rule, if you have headers that are
likely to change, then they need to be in the DEPENDPATH, otherwise, if they do
change, then your target(s) won't get rebuilt when they ought to.
A+
Paul
--
[ signature omitted ]
Message 4 in thread
In my case, I have INCLUDEPATH values that are not in DEPENDPATH because I
include some 3rd party libraries (and associated headers) that rarely (if
ever) change. And when they do change, I only need to link the new
libraries, I do not need anything recompiled.
Keith Esau, PDF Solutions
On 03-06-2006 10:28 AM, "Paul Floyd" <paulf@xxxxxxx> wrote:
> Quoting "Steven T. Hatton" <hattons@xxxxxxxxxxxxxxxxxx>:
>
>> The documentation says:
>> DEPENDPATH
>> This variable contains the list of all directories to look in to resolve
>> dependencies. This will be used when crawling through included files.
>>
>> Well, that's nice to know. What does it mean?
>
> makefiles consist of targets, rules and dependencies (and variables and
> extensions and other things, but let's forget them). And in short, the
> makefile
> says
>
> 'if any of these dependencies change, then use this rule to build the target'
>
> The DEPENDPATH controls the paths that are searched for dependencies. In
> practice, this means included headers. As a rule, if you have headers that are
> likely to change, then they need to be in the DEPENDPATH, otherwise, if they
> do
> change, then your target(s) won't get rebuilt when they ought to.
>
> A+
> Paul
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
> "unsubscribe" in the subject or the body.
> List archive and information: http://lists.trolltech.com/qt-interest/
>
--
[ signature omitted ]
Message 5 in thread
This is only true if this third-party provider guarantees the interface
not to change. If these are e.g. C++ headers, a simple change of the
order of instance variables is bound to render the worst segmentation
faults or even wrong results in calculations without any chance for you
to catch them, so linking a library using outdated headers is pretty
dangerous AFAIK.
Regards,
Daniel
Keith Esau schrieb:
> In my case, I have INCLUDEPATH values that are not in DEPENDPATH because I
> include some 3rd party libraries (and associated headers) that rarely (if
> ever) change. And when they do change, I only need to link the new
> libraries, I do not need anything recompiled.
>
> Keith Esau, PDF Solutions
>
> On 03-06-2006 10:28 AM, "Paul Floyd" <paulf@xxxxxxx> wrote:
>
>
>> Quoting "Steven T. Hatton" <hattons@xxxxxxxxxxxxxxxxxx>:
>>
>>
>>> The documentation says:
>>> DEPENDPATH
>>> This variable contains the list of all directories to look in to resolve
>>> dependencies. This will be used when crawling through included files.
>>>
>>> Well, that's nice to know. What does it mean?
>>>
>> makefiles consist of targets, rules and dependencies (and variables and
>> extensions and other things, but let's forget them). And in short, the
>> makefile
>> says
>>
>> 'if any of these dependencies change, then use this rule to build the target'
>>
>> The DEPENDPATH controls the paths that are searched for dependencies. In
>> practice, this means included headers. As a rule, if you have headers that are
>> likely to change, then they need to be in the DEPENDPATH, otherwise, if they
>> do
>> change, then your target(s) won't get rebuilt when they ought to.
>>
>> A+
>> Paul
>>
>> --
>> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
>> "unsubscribe" in the subject or the body.
>> List archive and information: http://lists.trolltech.com/qt-interest/
>>
>>
>
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with "unsubscribe" in the subject or the body.
> List archive and information: http://lists.trolltech.com/qt-interest/
>
>
--
[ signature omitted ]
Message 6 in thread
Quoting Daniel Walz <walz@xxxxxxxx>:
> This is only true if this third-party provider guarantees the interface
> not to change. If these are e.g. C++ headers, a simple change of the
> order of instance variables is bound to render the worst segmentation
> faults or even wrong results in calculations without any chance for you
> to catch them, so linking a library using outdated headers is pretty
> dangerous AFAIK.
I would always hope to be aware whenever the system/compiler/3rd party headers
that I use change, and when they do change, "make clean ; make" is not a big
deal.
I don't have any data on how much bigger/slower the resulting makefiles are, but
given that such changes (for me) are very infrequent, I don't think that it's at
all worth adding /usr/include, MSVS_ROOT/include, STLPORT/include etc to the
DEPENDPATH.
A+
Paul
--
[ signature omitted ]
Message 7 in thread
Regardless, when 3rd party libraries change, you MUST do a make clean
because their dates are still older than you recent build dates and nothing
would remake otherwise. Thus, you never set up dependencies on them.
And any third party library that is not backward compatible (without a major
good reason) is a bad idea. In my case, the libraries are guaranteed to be
backward compatible.
On 03-07-2006 4:23 AM, "Paul Floyd" <paulf@xxxxxxx> wrote:
> Quoting Daniel Walz <walz@xxxxxxxx>:
>
>> This is only true if this third-party provider guarantees the interface
>> not to change. If these are e.g. C++ headers, a simple change of the
>> order of instance variables is bound to render the worst segmentation
>> faults or even wrong results in calculations without any chance for you
>> to catch them, so linking a library using outdated headers is pretty
>> dangerous AFAIK.
>
> I would always hope to be aware whenever the system/compiler/3rd party headers
> that I use change, and when they do change, "make clean ; make" is not a big
> deal.
>
> I don't have any data on how much bigger/slower the resulting makefiles are,
> but
> given that such changes (for me) are very infrequent, I don't think that it's
> at
> all worth adding /usr/include, MSVS_ROOT/include, STLPORT/include etc to the
> DEPENDPATH.
>
> A+
> Paul
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
> "unsubscribe" in the subject or the body.
> List archive and information: http://lists.trolltech.com/qt-interest/
>
Keith Esau
Senior Software Engineer (dpSHEET)
PDF Solutions, Inc.
keith.esau@xxxxxxx
913-599-6537 (work/home)
913-515-2135 (mobile)
kaesau@xxxxxxxxxxxxx (home/personal)
--
[ signature omitted ]
