make dependency issue with OMNeT++ v4.2.1 IDE

811 views
Skip to first unread message

Jan Vogelgesang

unread,
Feb 16, 2012, 9:19:00 AM2/16/12
to omn...@googlegroups.com
Hello,

i have the same problem as already posted by Raphel Massin on Dec 21,
2011, but i am using OMNeT++ v4.2.1 on Linux.

The problem is that the makefile generated by the IDE does not include
any header dependecies (neither *.h nor *_m.h), see [1] for an example.
However, running "make depend" on the IDE generated makefile adds the
necessary dependencies to the makefile, see [2] for an example.

Calling opp_makemake from a shell (using parameters as shown by IDE)
generates the correct makefile, including the dependencies, in one step.

The problem shows up even on freshly generated projects in OMNeT++
v4.2.1 and OMNeT++ v4.2 on both Linux and (as reported by Raphel Massin)
Windows.
I just checked OMNeT++ v4.1 and the problem doesn't show up there.

Any suggestions what i should check additionally before filling a bug?

Regards,
jan


[1] excerpt from make file:
[.....]
# DO NOT DELETE THIS LINE -- make depend depends on it.
$O/cohon_api_base/CohonHandle.o: cohon_api_base/CohonHandle.cpp
$O/cohon_api_base/Publisher.o: cohon_api_base/Publisher.cpp
$O/cohon_routing_core/messages/ControlMessage.o:
cohon_routing_core/messages/ControlMessage.cpp
[.....]


[1] excerpt from make file:
[.....]
# DO NOT DELETE THIS LINE -- make depend depends on it.
$O/cohon_api_base/CohonHandle.o: cohon_api_base/CohonHandle.cpp \
./cohon_common/SequenceNumber.h \
src/base/logging.h \
./cohon_common/CoHoNMessageStructs.h \
./cohon_common/CohonTypedefs.h \
cohon_api_base/Publisher.h \
cohon_api_base/CohonHandle.h \
cohon_api_base/Subscriber.h \
./cohon_common/tee_ostreams.h \
src/base/singleton.h \
src/base/LogStream.h \
cohon_api_base/messages/Item.h \
./cohon_message_pipeline/Message.h \
./cohon_common/TopicID.h \
./cohon_common/TypeNameDemangling.h \
./cohon_message_pipeline/MessageBuffer.h \
./cohon_api_base/messages/Item.h \
./cohon_common/std.h \
cohon_api_base/TopicSubscriber.h \
./cohon_common/TopicProperties.h \
./cohon_api_base/SubscriberEvent.h
$O/cohon_api_base/Publisher.o: cohon_api_base/Publisher.cpp \
./cohon_common/SequenceNumber.h \
src/base/logging.h \
./cohon_common/CoHoNMessageStructs.h \
./cohon_common/CohonTypedefs.h \
cohon_api_base/Publisher.h \
./cohon_common/tee_ostreams.h \
src/base/LogStream.h \
src/base/singleton.h \
cohon_api_base/messages/Item.h \
./cohon_message_pipeline/Message.h \
./cohon_common/TopicID.h \
./cohon_message_pipeline/MessageBuffer.h \
./cohon_common/TypeNameDemangling.h \
./cohon_common/std.h \
./cohon_common/TopicProperties.h
cohon_routing_core/messages/ControlMessage.cpp \
src/omnet_messages/L2Message_m.h \
cohon_routing_core/messages/ControlMessage.h \
./cohon_common/CoHoNMessageStructs.h \
src/base/LogStream.h \
./cohon_message_pipeline/Message.h \
cohon_common/CohonTypedefs.h \
./cohon_common/TopicID.h \
./cohon_message_pipeline/MessageBuffer.h \
./cohon_common/TypeNameDemangling.h \
cohon_common/TopicID.h \
src/base/logging.h \
./cohon_common/CohonTypedefs.h \
cohon_routing_core/messages/L2Message.h \
./cohon_common/tee_ostreams.h \
src/base/singleton.h \
src/omnet_messages/ControlMessage_m.h \
./cohon_common/std.h
[.....]

MASSIN Raphael

unread,
Feb 16, 2012, 9:48:31 AM2/16/12
to omn...@googlegroups.com
Dear all,

I confirm that the problem still exists on Windows with v4.2.1.

Sincerely,

Raphaël

-----Message d'origine-----
De : omn...@googlegroups.com [mailto:omn...@googlegroups.com] De la part de Jan Vogelgesang
Envoyé : jeudi 16 février 2012 15:19
À : omn...@googlegroups.com
Objet : [Omnetpp-l] make dependency issue with OMNeT++ v4.2.1 IDE

Hello,

Regards,
jan

--
Sent from the OMNeT++ mailing list. To configure your membership,
visit http://groups.google.com/group/omnetpp

Rudolf Hornig

unread,
Feb 16, 2012, 10:44:44 AM2/16/12
to omn...@googlegroups.com
Is there a project available where I can check/reproduce the issue? Does it happen with INET?

Could you try a possible workaround:

- Build your projects.
- After it has failed, touch the .msg file where the missing file was and try to build again...

Rudolf

Jan Vogelgesang

unread,
Feb 17, 2012, 5:25:41 AM2/17/12
to omn...@googlegroups.com
Hello Rudolf, hello all,

On 16.02.2012 16:44, Rudolf Hornig wrote:
> Does it happen with INET?

I'am not using INET, just plain Omnet.

> Is there a project available where I can check/reproduce the issue?

I have included a sample project - it is an "Tictoc example" project
with minimal changes, however...

During preparation of the sample i discovered the issue is related to
the file extension used for source files throughout the project - using
".cc" is working fine, using ".cpp" shows the dependency issue.
(this is unaffected by the "C++ file extension" setting in Makemake options)

Hope that helps. And i would be happy if you have any hint for an
workaround or patch, as changing the file extension is not an option in
my project.

Regards,
jan

>
> On Thu, Feb 16, 2012 at 3:48 PM, MASSIN Raphael
> <raphael-...@thalesgroup.com

> <mailto:raphael-...@thalesgroup.com>> wrote:
>
> Dear all,
>
> I confirm that the problem still exists on Windows with v4.2.1.
>
> Sincerely,
>

> Rapha�l


>
> -----Message d'origine-----
> De : omn...@googlegroups.com <mailto:omn...@googlegroups.com>

> [mailto:omn...@googlegroups.com <mailto:omn...@googlegroups.com>]


> De la part de Jan Vogelgesang

> Envoy� : jeudi 16 f�vrier 2012 15:19
> � : omn...@googlegroups.com <mailto:omn...@googlegroups.com>


--
Jan Vogelgesang
Weltraumrobotik

Hauptadresse Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Stra�e 5
28359 Bremen, Germany

Besuchsadresse im Geb�ude Unicom 1:
Mary-Somerville-Stra�e 9
28359 Bremen, Germany

Phone: +49 (0)421 178 45-6654
Fax: +49 (0)421 178 45-6613
E-Mail: jan.vog...@dfki.de

Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Stra�e 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3
-----------------------------------------------------------------------

testHeaderDependency.tar.gz

Rudolf Hornig

unread,
Feb 20, 2012, 5:11:53 AM2/20/12
to omn...@googlegroups.com
Hello all,

I've tried both project, but they successfully compiled on my machine so there should be some additional problem somewhere. I just extracted the archives, imported into OMNET 4.2.1 and started the build from the IDE.

As as side note: omnet's build system supports only the .cc files correctly. *.cpp files may or may not work correctly, we do not test whether opp_makemake generates correct makefiles for them.

If possible I suggest to switch to .cc

Rudolf

On Fri, Feb 17, 2012 at 11:25 AM, Jan Vogelgesang <jan.vog...@dfki.de> wrote:
Hello Rudolf, hello all,

On 16.02.2012 16:44, Rudolf Hornig wrote:
> Does it happen with INET?
I'am not using INET, just plain Omnet.

> Is there a project available where I can check/reproduce the issue?
I have included a sample project - it is an "Tictoc example" project
with minimal changes, however...

During preparation of the sample i discovered the issue is related to
the file extension used for source files throughout the project - using
".cc" is working fine, using ".cpp" shows the dependency issue.
(this is unaffected by the "C++ file extension" setting in Makemake options)

Hope that helps. And i would be happy if you have any hint for an
workaround or patch, as changing the file extension is not an option in
my project.

Regards,
jan

>
> On Thu, Feb 16, 2012 at 3:48 PM, MASSIN Raphael
> <raphael-...@thalesgroup.com
> <mailto:raphael-...@thalesgroup.com>> wrote:
>
>     Dear all,
>
>     I confirm that the problem still exists on Windows with v4.2.1.
>
>     Sincerely,
>
>            Raphaël

>
>     -----Message d'origine-----
>     De : omn...@googlegroups.com <mailto:omn...@googlegroups.com>
>     De la part de Jan Vogelgesang
>     Envoyé : jeudi 16 février 2012 15:19
Robert-Hooke-Straße 5
28359 Bremen, Germany

Besuchsadresse im Gebäude Unicom 1:
Mary-Somerville-Straße 9

28359 Bremen, Germany

Phone: +49 (0)421 178 45-6654
Fax:   +49 (0)421 178 45-6613
E-Mail: jan.vog...@dfki.de

Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern

Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.:    DE 148646973
Steuernummer:  19/673/0060/3
-----------------------------------------------------------------------

Jan Vogelgesang

unread,
Feb 20, 2012, 11:15:44 AM2/20/12
to omn...@googlegroups.com
Hello all, hello Rudolf,

On 20.02.2012 11:11, Rudolf Hornig wrote:
> I've tried both project, but they successfully compiled on my machine so
> there should be some additional problem somewhere. I just extracted the
> archives, imported into OMNET 4.2.1 and started the build from the IDE.

Maybe there is a misunderstanding: The project also builds on my
machine, regardless if using .cc or .cpp. However, the makefile
generated by the IDE (!) differs.

Excerpt from makefile using .cc suffix:
...


# DO NOT DELETE THIS LINE -- make depend depends on it.

$O/Txc.o: Txc.cc \
Txc.h \
someheader.h

Excerpt from makefile using .cpp suffix:
...


# DO NOT DELETE THIS LINE -- make depend depends on it.

$O/Txc.o: Txc.cpp

Thus, after changing 'someheader.h' a 'make all' will rebuild Txc.o when
using .cc suffix, and will do nothing when using .cpp suffix.
Could you reproduce this ?


> As as side note: omnet's build system supports only the .cc files
> correctly. *.cpp files may or may not work correctly, we do not test
> whether opp_makemake generates correct makefiles for them.

opp_makemake always creates the correct makefile, only the IDE creates a
makefile with incomplete dependencies when using .cpp !
This bug was introduced in OMNeT++ v4.2, previous versions of the IDE
handles .cpp files correctly.

I wasn't aware of the fact that OMNeT doesn't support .cpp suffixes in
the same way as .cc. I am really surprised to hear this, because in
numerous places (Documentation, IDE, "opp_makemake --help") both
suffixes are mentioned equally. Are you sure this is correct (and known
by all omnet developers)?

Regards
jan


> On Fri, Feb 17, 2012 at 11:25 AM, Jan Vogelgesang
> <jan.vog...@dfki.de <mailto:jan.vog...@dfki.de>> wrote:
>
> Hello Rudolf, hello all,
>
> On 16.02.2012 16:44, Rudolf Hornig wrote:
> > Does it happen with INET?
> I'am not using INET, just plain Omnet.
>
> > Is there a project available where I can check/reproduce the issue?
> I have included a sample project - it is an "Tictoc example" project
> with minimal changes, however...
>
> During preparation of the sample i discovered the issue is related to
> the file extension used for source files throughout the project - using
> ".cc" is working fine, using ".cpp" shows the dependency issue.
> (this is unaffected by the "C++ file extension" setting in Makemake
> options)
>
> Hope that helps. And i would be happy if you have any hint for an
> workaround or patch, as changing the file extension is not an option in
> my project.
>
> Regards,
> jan
>
> >
> > On Thu, Feb 16, 2012 at 3:48 PM, MASSIN Raphael
> > <raphael-...@thalesgroup.com
> <mailto:raphael-...@thalesgroup.com>

> > <mailto:raphael-...@thalesgroup.com


> <mailto:raphael-...@thalesgroup.com>>> wrote:
> >
> > Dear all,
> >
> > I confirm that the problem still exists on Windows with v4.2.1.
> >
> > Sincerely,
> >

> > Rapha�l


> >
> > -----Message d'origine-----
> > De : omn...@googlegroups.com
> <mailto:omn...@googlegroups.com> <mailto:omn...@googlegroups.com
> <mailto:omn...@googlegroups.com>>

> > [mailto:omn...@googlegroups.com


> <mailto:omn...@googlegroups.com> <mailto:omn...@googlegroups.com
> <mailto:omn...@googlegroups.com>>]
> > De la part de Jan Vogelgesang

> > Envoy� : jeudi 16 f�vrier 2012 15:19

> > � : omn...@googlegroups.com <mailto:omn...@googlegroups.com>
> <mailto:omn...@googlegroups.com <mailto:omn...@googlegroups.com>>

Rudolf Hornig

unread,
Feb 21, 2012, 4:52:15 AM2/21/12
to omn...@googlegroups.com
Hi, I can confirm and reproduce the issue. I just want to give a bit more info about the reason:

Till 4.1 both the IDE and the command line opp_makemake generated the dependencies more or less the same way. It was basically scanning the files and looking for #include statements. Whatever it found it added to the dependency. While this works most of the time, this is not a correct solution because #include statements between #ifdef statements are always included too. With the introduction of "Project Features" in 4.2 we got a lot of similar ifdef blocks (in INET primarily) and the dependencies were incorrect in these cases (you had the dependencies from features that were turned out). To figure out which #includes are relevant and which ones are excluded we had to rely on CDT's indexer so the dependency generator was rewritten in the IDE to use the output from the CDT indexer.

The original approach for the opp_makemake was that you had to specify on the command line whether you are using .cc or .cpp files in your project (it was not possible to mix both). This is in fact also a bad behavior (it just should work without any issues with both extension (even if mixed)). This (bad) behavior was not re-implemented in IDE, but rather we opted to use only .cc for now and add *correct* support for both .cc and .cpp in a later release.

Long story short, this is a missing/postponed feature for the IDE and you are welcome to post an issue in the bugtracker so you will be able to keep an eye when it will be implemented (or push it a bit if that is important for you. we tend to work on issues where people are active :) )

A workaround (for now): 
- you can either rename the files to have .cc extension
- or you can generate your makefile manually with opp_makemake from the command line and switch the makefile generation (for that source folder) to manual in the IDE project so the IDE will not overwrite it each time you build your projects...

Rudolf

>     >            Raphaël

>     >
>     >     -----Message d'origine-----
>     >     De : omn...@googlegroups.com
>     <mailto:omn...@googlegroups.com> <mailto:omn...@googlegroups.com
>     <mailto:omn...@googlegroups.com>>
>     >     [mailto:omn...@googlegroups.com
>     <mailto:omn...@googlegroups.com> <mailto:omn...@googlegroups.com
>     <mailto:omn...@googlegroups.com>>]
>     >     De la part de Jan Vogelgesang
>     >     Envoyé : jeudi 16 février 2012 15:19
>     >     À : omn...@googlegroups.com <mailto:omn...@googlegroups.com>

Jan Vogelgesang

unread,
Feb 21, 2012, 12:03:07 PM2/21/12
to omn...@googlegroups.com
Hello,

Rudolf, thank you very much for your explanation I will add an entry to
the bugtracker soon.

I would like to share another workaround with the list:

Create a small shell script containing the following:
#!/bin/sh
make depend
make MODE=$1 CONFIGNAME=$2 -j6 $3

and call this script as the "Build command" (Project properties -> C/C++
Build) in Eclipse. And of course: adapt the second line to your needs.
This uses the same dependency resolution as opp_makemake, but you can
continue to use the automatic makefile generation and the nice makemake GUI.

Regards,
Jan

Rudolf Hornig

unread,
Feb 21, 2012, 2:56:30 PM2/21/12
to omn...@googlegroups.com
Yes, this is also a possible solution (overwriting the dependencies generated by the IDE before each build), however this would make the Makefile always out of date on each build. This practically means that it will relink the library always (even if there was no change in sources). In practice this is acceptable.

The same solution without external script:

In Project | Properties | C/C++ Build on the Behavior tab, specify "depend all" (without the quotes) for the Incremental build targets. This will invoke first the depend target and then the all target. (I'm not sure if this trick is compatible with the parallel build feature tough )

Or the same thing: you can create a 'makefrag' file and specify

all: depend 

in it, meaning that the default all target always depend on 'depend'

Pick your favorite :)

Rudolf

Reply all
Reply to author
Forward
0 new messages