Qt update

[Tomaz Canabrava]

2013/4/9 Dirk Hohndel <dirk at hohndel.org>

> Alberto Mardegan <mardy at users.sourceforge.net> writes:
>
> > Hi,
> >
> > On 04/08/2013 03:36 AM, Dirk Hohndel wrote:
> >> I worked with Tomaz to get his build issues sorted out. The solution was
> >> just pushed to the Qt branch. The Makefile in there isn't exactly where
> >> I would want to be, but it seems to work for him (and me) and allows the
> >> Qt UI development to move forward.
> >
> > I'll check it later tonight. Strange that it had to be moved, though.
>
> Not sure what you mean by "it" in that last sentence.
>
> I think we agreed that all UI code should reside in qt-ui/ so that's
> where all the classes are.
>
> Tomaz removed some of your code (and changed his commit to just use a
> #ifdef to not compile it in qt-gui.cpp) since he thought you were
> calling into Gtk specific code and he wanted a clean start. Looking at
> your code I'm actually not sure he is right and am tempted to move that
> into the MainWindow class that Tomaz created in qt-ui/mainwindow.cpp -
> but then, I don't want to step on his toes, either :-)
>
> >> There are two things we'd rather have differently in the Makefile but my
> >> make-foo is insufficient to make that happen
> >>
> >> a) right now I need to explicitly create the dependency from the moc and
> >> ui_*.h files to the object file in order to get those rebuilt. Is there
> >> a way to detect the need to build those and create the dependencies
> >> automagically? Maybe for every .cpp file in qt-ui ?
> >>
> >> qt-ui/maintab.o: qt-ui/maintab.moc qt-ui/ui_maintab.h
> >
> > My make-fu is also insufficient to work out a way to detect the
> > dependencies, but an approach based on the file name is quite easy to
> > produce.
> >
> > Something like
> >
> >    qt-ui/%.o: qt-ui/%.moc qt-ui/ui_%.h
>
> Yes, that should be able to avoid the individual dependencies. Nice.
>
> > assuming that all files in qt-ui need this. If not, I'll give it a try
> > with make-fu as well: I suppose that something like this *might* work:
> >
> > # Find which object files need this special treatment
> > OBJS_NEEDING_MOC = $(grep -l '^#include ".*\.moc"' $(OBJS:.o=.c))
> >
> > # Extra dependency for the files found above
> > $(OBJS_NEEDING_MOC): qt-ui/%.o: qt-ui/%.moc qt-ui/ui_%.h
> >
> > See http://www.gnu.org/software/make/manual/html_node/Static-Usage.html
>
> Cool. I should have thought of that. Do you want to send a patch or
> should I just apply it and add your Signed-off-by ?
> (I know people think this is silly, but I need either a signed-off patch
> or an explicit "yes, please add my SOB"...)
>
> >> b) right now the .cpp files have to manually include the .moc files at
> >> the end. I'm sure we could have the Makefile automatically compile the
> >> .moc files and add them to the objects that are linked together.
> >>
> >> I'm pretty sure that's what the .moc.cpp style rules were supposed to
> >> do, but I couldn't make that work for me.
> >
> > Nope, I'm afraid that that #include at the end must stay. The reason is
> > that the #include'd .moc file defines some methods/members for a class
> > which is declared in the .cpp file. Therefore, if you compiled it
> > separately, the compiler wouldn't find the declaration of the class, and
> > would spit errors.
>
> Someone (I think it was Tomaz, but I'm losing track) mentioned that
> alternatively they could be compiled separately and then linked
> together. But I'm fine with the #include if that's what it has to be...
>
>
Since no class is declared in the .cpp files yet, I removed.


> >> So if any of the Makefile Magicians would like a little challenge...
> >> patches welcome :-)
> >
> > I hope I'll have time tonight. If not, tomorrow is another day :-)
>
> I understand the feeling :-)
>
> Your help is appreciated.
>
> /D
> _______________________________________________
> subsurface mailing list
> subsurface at hohndel.org
> http://lists.hohndel.org/cgi-bin/mailman/listinfo/subsurface
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.hohndel.org/pipermail/subsurface/attachments/20130409/2befcc80/attachment.html>