Hi Brad please help I have an odd error in my Qt project on Windows but it seems to be being caused by qmake when it auto generates my makefile.

I just created a new project, I haven’t added any code yet but when I try to compile it I get the following error:

mingw32-make[1]: *** No rule to make target '../../this_is_my_solution_directory/this_is_my_projectects_unittests/this_is_my_projectects_unittests.pro', needed by 'Makefile'.  Stop.

I had this exact problem just yesterday and it drove me up the wall. I thought it was something I missed as I was hand rolling a sub directory project but I then tried to create my sub directory project structure using Qt Creator’s built in wizards and just like you without modifying it in any way and just using the auto generated code I got the exact same issue.

Turns out its not make or qmakes fault but your operating system, your projects relative path is just to long.

The project I was creating was a little tool for generating Star English translation files for Qt ( found here ). The project hierarchy was as follows:

• StarEnglish_Generator_For_Qt
  • starenglishgeneratorapp
  • starenglishgeneratorlib
  • starenglishgeneratorunittests

When I built the top level solution I would get the following error:

mingw32-make[1]: *** No rule to make target '../../StarEnglish_Generator_For_Qt/starenglishgeneratorunittests/starenglishgeneratorunittests.pro', needed by 'Makefile'.  Stop.

For the life of me I could not figure it out, especially because I could build the starenglishgeneratorapp and starenglishgeneratorlib projects and if I opened the starenglishgeneratorunittests project by itself (out side of the sub directory hierarchy) it would build just fine.

The difference I noticed was that when trying to build the starenglishgeneratorunittests project in the sub directory solution the relative path used was: ../../StarEnglish_Generator_For_Qt/starenglishgeneratorunittests/starenglishgeneratorunittests.pro (98 characters long) but when building it on its own the path used was ../starenglishgeneratorunittests/starenglishgeneratorunittests.pro (66 characters long). Also noticing that the starenglishgeneratorunittests project was my longest named project I realized I was looking at a path length problem.

To test this I created a new stand-alone project named wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww (54 characters long) and found that it too failed with the following error:

mingw32-make: *** No rule to make target '../wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww/wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww.pro', needed by 'Makefile'.  Stop.Stop.

Notice that the relative path being used is 116 characters long.

I started making smaller and smaller named projects until I got to 51 characters (wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww) which produced this error:

mingw32-make[1]: *** No rule to make target '../wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww/tst_WwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwTest.cpp', needed by 'debug/tst_WwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwTest.o'.  Stop.

Which is different but caused by the same issue, path length, this time the relative path which includes the CPP file is 118 characters long.

Finally when I made a project whose name was only 50 characters long (wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww) did I resolve my path length issues and seen a successful compile.

With that knowledge in mind I renamed my Star English Generator projects to reduce their over all path length and voila a successful build.

So let it be known that the relative path lengths of your project files (both to the *.pro and the *.hpp/*.cpp files) have an upper limit that if you exceed your makefiles will start throwing can’t find file errors. The exact max path will differ between operating systems; I ran into this on Windows 7.

I guess the take away here is that the code we write should be explicit and take advantage of all the pixels in our modern large resolution monitors (stop writing m_enFlag when m_enabledFlag makes things so much more clear) but when it comes to file/folder/project names the conservation of characters is a good thing.

Until next time think imaginatively and design creatively