MADDE's qmake generates incorrect makefiles for Windows - where to file bug? - maemo.org

Active Topics

Maemo repository (13)
to Community by nieldk - 1 day, 7 hrs ago
Error after installing Leste on sdcard (18)
to Maemo 7 / Leste by Maemish - 3 days, 7 hrs ago
Maemo 20th Anniversary (4)
to Brainstorm by teroyk - 5 days, 2 hrs ago
Nokia Booklet 3G (RX-75) Drivers (64)
to Alternatives by teroyk - 5 days, 2 hrs ago
more...

Page 1 of 3

Next >

Thread Tools

RCL	2010-05-22 , 12:17
Posts: 13 \| Thanked: 3 times \| Joined on May 2010 @ Russian working in Poland for an US company :)	#1

Hi,

if .pro file contains sources in parent directories, e.g. like

HEADERS += ../../../whatever/header.h

then qmake for Windows (more exactly .madde/0.6.14/targets/fremantle-qt-0951/bin/qmake.exe) will generate a makefile which will have "native" Windows backslashes for header dependencies, e.g.

../build/whatever.o: ../../../whatever/whatever.cpp ..\..\..\whatever\header.h

The problem is, that make (also from MADDE) will understand the backslashes as escaped symbols and will refuse to build such a makefile (it won't find header.h). Manually replacing backslashes with slashes fixes the problem but it's an unfeasible solution.

It only happens on Windows MADDE setup, on Ubuntu everything is Ok (only slashes are used obviously). Windows native qmake (from QT SDK for PC) also handles such .pro files correctly, placing slashes in a makefile.

I know that MADDE is still BETA, but I would like to report a bug against that nevertheless just to let developers know.

If there's a better place for bugreports against MADDE, let me know, please.

Quote & Reply |

The Following User Says Thank You to RCL For This Useful Post:
Larswad

Joorin	2010-05-22 , 12:27
Posts: 726 \| Thanked: 345 times \| Joined on Apr 2010 @ Sweden	#2

Isn't it better to not use relative includes? Add the correct -I flag instead and it will work even if you move your code around.

Quote & Reply |

The Following User Says Thank You to Joorin For This Useful Post:
RCL

RCL	2010-05-22 , 12:37
Posts: 13 \| Thanked: 3 times \| Joined on May 2010 @ Russian working in Poland for an US company :)	#3

Well, actually you are right and not specifying anything in HEADERS fixes that too

But there are downsides of that:
1) you cannot see your headers in project browser in QtCreator
2) I believe, that for Qt builds you have to specify headers in HEADERS sometimes.

So to sum up, I think it's still a bug worth fixing.

Quote & Reply |

gri	2010-05-22 , 18:03
Posts: 190 \| Thanked: 129 times \| Joined on Mar 2010 @ Bavaria, Germany	#4

Are you sure you really executed "mad qmake"?

Mine just works fine:

Code:

o2_germany.o: o2_germany.cpp o2_germany.hpp \
		../providerinterface.hpp \
		../contactinfo.hpp \
		../export.hpp \
		../providerplugin.hpp \
		../accountsettingsdialog.hpp \
		o2_germany.moc
	$(CXX) -c $(CXXFLAGS) $(INCPATH) -o o2_germany.o o2_germany.cpp

Quote & Reply |

RCL	2010-05-23 , 11:44
Posts: 13 \| Thanked: 3 times \| Joined on May 2010 @ Russian working in Poland for an US company :)	#5

Well, I don't execute mad qmake, I'm using QtCreator which executes qmake from freemantle directory itself. Executing qmake from the same location manually (that is, cd'ing to directory where .pro is located and then invoking qmake with absolute path) has the same effect.

Regarding your results, are you listing those headers in HEADERS variable or does qmake find them as dependencies itself?

I found that automatically found dependencies are generated correctly (thanks to Joorin for an obvious solution), and only those headers that are also listed in HEADERS are affected.

I'm also using more than one level of ../ indirection, which may or may not affect the results.

Quote & Reply |

gri	2010-05-23 , 13:17
Posts: 190 \| Thanked: 129 times \| Joined on Mar 2010 @ Bavaria, Germany	#6

I've never added "../" to HEADERS.

In my opinion there is no reason to do this. If you want to use the code of a directory "upper", make a shared/static library of them. On this way you also see the headers and sources.

If you don't like that solution, create a "whatever.pri" which contains "HEADERS += $$PWD/header.h" and in your project which is using it add "include(../../../whatever/whatever.pri)"

By the way: If you ONLY add headers which don't even contain Q_OBJECT macros, this is just for beauty and doesn't mean anything for the compiler. (I suppose you know that

)

Last edited by gri; 2010-05-23 at 13:19.

Quote & Reply |

rontti	2010-05-24 , 11:51
Posts: 62 \| Thanked: 97 times \| Joined on Dec 2009 @ Finland, Kerava	#7

The bug is fixed in upcoming MADDE release.

Quote & Reply |

The Following 2 Users Say Thank You to rontti For This Useful Post:
danielwilms, RCL

RCL	2010-05-25 , 10:27
Posts: 13 \| Thanked: 3 times \| Joined on May 2010 @ Russian working in Poland for an US company :)	#8

Originally Posted by gri

I've never added "../" to HEADERS.

In my opinion there is no reason to do this. If you want to use the code of a directory "upper", make a shared/static library of them. On this way you also see the headers and sources.

If you don't like that solution, create a "whatever.pri" which contains "HEADERS += $$PWD/header.h" and in your project which is using it add "include(../../../whatever/whatever.pri)"

My situation is like this:

I have a set of directories that contain cross-platform code (without .pro files) and a set of directories that hold platform-dependent code (and .pro files - but some projects use different build systems) for various platforms. It's basically like:

Code:

/libraries/
   /math
   /utilities
   /objects
   ...

/projects/
   /maemo
      ... (maemo projects)
   /pc
      ... (pc projects)
   /ps3
   ...

So projects often refer to files in /libraries directory and its subdirectories (even libraries still have their .pro files under /projects because they are often platform-specific - merging all the possible setups in a single .pro file would make it messy and also vulnerable to breaking compilation for some platform and not noticing it), but in order to get there without using absolute paths (I want minimal setup on different OSes without environment variables etc), I have to use relative paths.

If you think that's totally wrong, I'd be glad to hear your propositions, but we probably should not spam this thread

(perhaps private msg would be better?)

Originally Posted by gri

By the way: If you ONLY add headers which don't even contain Q_OBJECT macros, this is just for beauty and doesn't mean anything for the compiler. (I suppose you know that )

Yeah, that's why I said that including files in HEADERS was sometimes necessary

I forgot the exact reason and now you reminded me, thanks!

Anyway, I'm really glad that this issue will be fixed in the next MADDE. Thanks to the dev team!

Last edited by RCL; 2010-05-25 at 10:33.

Quote & Reply |

	too	2010-05-28 , 11:24
	Posts: 122 \| Thanked: 135 times \| Joined on Dec 2009 @ Helsinki	#9

And now fixed MADDE is available, version 0.6.72

at http://tablets-dev.nokia.com/MADDE.php

Quote & Reply |

The Following User Says Thank You to too For This Useful Post:
RCL

RCL	2010-06-01 , 15:09
Posts: 13 \| Thanked: 3 times \| Joined on May 2010 @ Russian working in Poland for an US company :)	#10

This is from Qt Creator, first step after adding a new Qt version - rebuilding helpers.

Code:

Building debugging helper library in D:/RCL/local/MADDE/0.6.72/sysroots/fremantle-arm-sysroot-10.2010.19-1-slim/usr/share/qt4/qtc-debugging-helper/

Running D:/rcl/local/madde/0.6.72/bin/make.exe distclean...
make: *** No rule to make target `..\mkspecs\default\qmake.conf', needed by `Makefile'.  Stop.

Running d:/rcl/local/madde/0.6.72/targets/fremantle-pr12/bin/qmake.exe ...

Running D:/rcl/local/madde/0.6.72/bin/make.exe ...
make: *** No rule to make target `..\mkspecs\default\qmake.conf', needed by `Makefile'.  Stop.

..\mkspecs\default\qmake.conf exists and is reachable from qtc-debugging-helpers. Seems like backslashes aren't really fixed... (previous MADDE 0.6.14 was actually able to rebuild helpers)