Re: TrackerRequestDriver feedback

Hi Peter,

I think I’d call Sources Calitko. Maybe CalitkoMocks better be in . or in ./Utils - the idea is that it eventually becomes a standalone library.Maybe the built binary should be copied to AppData by make?

Ok.

Maybe the built binary should be copied to AppData by make?

I was thinking that only application data (icons, images, …) would be there at first and we’ll leave the application binary in the root dir.

There is indeed a problem - because we make extensive use of “packages”, we might have, and in fact have, modules in different packages having the same name. If all object files are created in a “flat” Objects or Builds dir, we would have dependencies overwriting each other (e.g. Package1/Module.cpp producing Module.o and Package2/Module.cpp producing Module.o). Long time ago I patched qmake to append an index to duplicating object files and I even submitted it to Qt but they rejected it. The argument was that not all build systems support it and that having duplicate filenames is a bag idea anyway (well, I don’t agree with that). The solution would have been to use the qmake subdirs template and create a lib project for each package - ughr! I think I got my patch to work almost fine for GCC. If I remember correctly, the last problem I had was if a new “duplicate” file was added to the project, the object file indices could change, resulting in the object files on disk no longer matching the correct source file. If we say we could live with that, I think I could patch our bundled qmake (it wasn’t bundled at that time yet) - I hope I find my old patches somewhere. [cut]

Ah, I see… I absolutely forgot that when I was writing the post! We were not using any “packages” (only few namespaces) and our sources had unique names.

I also once tried to replicate the source tree in the objects dir but I had some problem, which I don’t remember.

I was actually thinking about this solution when I was reading your reply :). Now it depends on whether there was a problem creating it (I mean dynamically using qmake - simple python script could do that, but it would bring us compilation-time dependancy on python) or when putting there object files.

There were in fact many bugs in qmake that wouldn’t have appeared in a flat directory structure project. At a certain point I decided to bundle qmake with Calitko and patch it when the need arises (and I had to a few times). This allows us to be independent of Qt releases and even implement one of the two solutions I wrote about above.

Yes, that’s a good idea, if there are some problems with the original qmake or we just need to extend it to better fit our needs.

Have a nice day,

Petr

Would you like to post a relpy?


This post is a reply to:
Re: TrackerRequestDriver feedback
Hi Petr, I’m thinking about something like this, you can check it out, too: - 3rdParty (cppunit, moc, qmake) - Sources (Protocols, UIs, Utils, CalitkoMocks, …) - Utils (templater and other possible stuff that (more...)

Follow-ups:
Re: TrackerRequestDriver feedback
Hi Petr, Maybe the built binary should be copied to AppData by make? I was thinking that only application data (icons, images, …) would be there at first (more...)