[Scons-users] Fwd: Scons-Qt5 questions / How can I generate Qt5 files into custom directories? - How can I debug and influence file dependencies?

Tue Jul 5 09:26:50 EDT 2016

Attaching back to the user's list. Missed a reply option.

---------- Forwarded message ----------
From: William Blevins <wblevins001 at gmail.com>
Date: Tue, Jul 5, 2016 at 1:33 PM
Subject: Re: Scons-Qt5 questions / How can I generate Qt5 files into custom
directories? - How can I debug and influence file dependencies?
To: Marco Buczilowski <mbu at delcam.de>

Marco,

It seems like you are starting to put things together. I just want to say a
few things about how SCons finds dependencies that may add additional
clarity or simply confirm your own thoughts. The core SCons build system
uses three components: emitters, actions (which includes builders), and
scanners. This is an important notion when thinking about how dependencies
are created because each component has a different role. Emitters handle
explicit dependencies (IE. A.c produces A.o) while Scanners handle implicit
dependencies (IE. A.c includes A.h). Explicit dependencies can be added to
the dependency tree without the target/source existing because this is a
fundamental translation rule; however, implicit dependencies require that
sources exist, so that they can be parsed in order to find includes or
imports. This means that if explicit dependencies are not created correctly
(file isn't in the correct directory or doesn't have the correct name),
then implicit scanning will always fail.

You may be able to get more help if you give more information. Right now we
can only give you some fundamentals, but I think they will give you the
insight you need to create custom builders, etc. SCons provides functions
to be able to handle how elements in the dependency tree are interacted
with: Requires, Depends, Clean, Precious, SideEffect, etc. There functions
will allow you to control how nodes are manipulated.

What you want to do with your custom uic generator is create a SCons tool
which wraps the generate function. This way you can associate the
input/output of your function with the SCons dependency tree. Please see
some simple examples: https://bitbucket.org/scons/scons/wiki/ToolsForFools.
If you have tools that produce more than 1 output from a single input (the
translation is 1:N) and this translation is input specific (IE. *.java ->
*.class like with java source generators) this becomes a little trickier:
https://bitbucket.org/scons/scons/wiki/DynamicSourceGenerator. I don't
think this is your case, but you may find the information useful in your
evaluation.

V/R,
William

On Tue, Jul 5, 2016 at 1:10 PM, Marco Buczilowski <mbu at delcam.de> wrote:

> Hi William,
>
>
>
> first of all: Thanks for taking the time.
>
>
>
> The link you’ve posted was interesting indeed. Today I’ve modified the
> project structure and tried a lot of different things, but whatever I do,
> the ui files are not being translated.
>
>
>
> I’ve found out, that the implementation of our Qt libraries differ from
> the Qt standard. One example is, that the moc files are not being included
> by the widget source files. At the moment I believe, that one of our
> variations from the Qt standard may prevent the plugin from translating the
> ui files. It sounds reasonable, that SCons can’t find dependencies from a
> non-existing file to another non-existing file, if some key references at
> the existing source files are non-standard.
>
>
>
> But anyway. Today I wrote my own implementation for the uic generator. It
> creates all ui header files directly. I know it’s not the best solution,
> because the files are not deleted on clean-up (as an example), but it‘s
> enough for me now.  At the moment I just want to evaluate SCons as a build
> system for our software. Later on, I might invest more time to improve the
> build scripts.
>
>
>
> *As for the output folder for generated files: *
>
> *This seems to be complicated as generated files may include existing
> source files and the generated include paths would have to be set right. I
> guess, this is the reason, why all the files should be in the same folder
> for automatic processing:*
>
>
>
> *>Automatic moc file generation from header files.* You do not have to
> specify moc files explicitly, the tool does it for you. However, there are
> a few preconditions to do so: Your header file must have the same filebase
> as your >implementation file and *must stay in the same directory*. It
> must have one of the suffixes .h, .hpp, .H, .hxx, .hh. You can turn off
> automatic moc file generation by setting QT_AUTOSCAN to 0. See also the
> corresponding Moc() builder >method.
>
>
>
> But I’m not sure, if that really is the reason.
>
>
>
> Regards,
>
> Marco
>
>
>
> Date: Mon, 4 Jul 2016 20:30:49 +0100
>
> From: William Blevins <wblevins001 at gmail.com>
>
> To: SCons users mailing list <scons-users at scons.org>
>
> Subject: Re: [Scons-users] Scons-Qt5 questions / How can I generate
>
>                 Qt5 files into custom directories? - How can I debug and
> influence
>
>                 file dependencies?
>
> Message-ID:
>
>                 <
> CALJHx11mw5j0x1VPzAAqnUX27epP1S_A=9qLKfXR+_gCZ96bzA at mail.gmail.com>
>
> Content-Type: text/plain; charset="utf-8"
>
>
>
> Marco,
>
>
>
> 1. Your example shows a custom builder, but the default Moc only has an
> input source correct? I'm not an expert with Moc, but generally with SCons
> you need to set SCons environment variables related to the builder if the
> underlying tool sets a feature via commandline parameter (which I assume
> Moc does). Try QT_MOCCXXPREFIX as specified here:
>
> http://scons.org/doc/production/HTML/scons-user.html#cv-QTDIR
>
>
>
> 2. SCons scanners look for files based on standard paths. CXX headers will
> only be found if they exist in the include path for example.
>
>
>
> Let me know if that helps,
>
> William
>
>
>
>
>
> On Mon, Jul 4, 2016 at 3:40 PM, Marco Buczilowski <
> marco.buczilowski at autodesk.com> wrote:
>
>
>
> > Hello everyone,
>
> >
>
> >
>
> >
>
> > three weeks ago I started evaluating Scons as build system for a
>
> > medium sized project. It all went well and I like the flexibility,
>
> > which is important, because I have to use an existing project structure.
>
> > For the next step I have to create build scripts for the user
>
> > interface libraries, which are based upon QT version 5. This part
>
> > seems to be tricky and I'd appreciate to get some help and advice from
> you.
>
> >
>
> >
>
> >
>
> > The project structure looks like this:
>
> >
>
> >
>
> >
>
> > *Static interface library*
>
> >
>
> > + (Folder)header files
>
> >
>
> > + (Folder)private header files
>
> >
>
> > + (Folder)Forms (qt ui files)
>
> >
>
> > + (Folder)GeneratedFiles (moc files, ui header, processed resource
>
> > + files)
>
> >
>
> > + (Folder)Source
>
> >
>
> > (File) qt translation file (.ts)
>
> >
>
> > (File) qt resource file (.qrc)
>
> >
>
> >
>
> >
>
> > What I want scons to do is:
>
> >
>
> > * Search for ui files in Forms and generate headers into the
>
> > GeneratedFiles folder
>
> >
>
> > * Search for translation files in project root and generate binary
>
> > translation file
>
> >
>
> > * Search for qrc files in root and generate cpp files in
>
> > GeneratedFiles folder
>
> >
>
> > * Use the automoc feature to moc Qt classes
>
> >
>
> > * compile everything
>
> >
>
> >
>
> >
>
> > I already got scons to complete single tasks, but for several reasons
>
> > I don't get it all together.
>
> >
>
> >
>
> >
>
> > First important question: Is it possible and solid to generate Qt
>
> > files into a custom directory. I tried things like this:
>
> >
>
> >
>
> >
>
> > > for qtUiSourceFile in qtUiSourceFiles:
>
> >
>
> > >     destination_file =
>
> > File(os.path.join(os.path.join('.','GeneratedFiles'), 'ui_' +
>
> > qtUiSourceFile.name.replace('.ui', '.h')))
>
> >
>
> > >     modCEnv.ExplicitUic5(destination_file, qtUiSourceFile)
>
> >
>
> >
>
> >
>
> > And how would I specify the destination for moc, resource and
>
> > translation files?
>
> >
>
> >
>
> >
>
> > The automoc feature seems to work fine, with the exception, that the
>
> > moc files are generated into the source directory at the moment. The
>
> > same applies to the resource files.
>
> >
>
> >
>
> >
>
> > The main problem I'm struggeling with is, that SCons doesn't seem to
>
> > find a reference from the Qt widget?s header file, to the generated ui
> header.
>
> > Maybe it has something to do with the fact, that the ui and the
>
> > generated header files are in different directories.
>
> >
>
> > The reference would be:
>
> >
>
> >   moc_FcQErrorLog.cc has to be compiled. it includes
>
> >
>
> >   FcQErrorLog.h which includes the generated
>
> >
>
> >   ui_fby_problem_widget.h
>
> >
>
> >
>
> >
>
> > SCons seems to know about the ui files, because they are part of the
>
> > dependency tree.
>
> >
>
> >
>
> >
>
> >     | | | +-src_unique\L50\ Qt-Utilities\fby_qt_js.dev\Form
>
> >
>
> >     | | | | +-src_unique\L50\
>
> > Qt-Utilities\fby_qt_js.dev\Form\fby_problem_widget.ui
>
> >
>
> >     | | | +-src_unique\L50\ Qt-Utilities\fby_qt_js.dev\GeneratedFiles
>
> >
>
> >     | | | | +-src_unique\L50\
>
> > Qt-Utilities\fby_qt_js.dev\GeneratedFiles\ui_fby_problem_widget.h
>
> >
>
> >     | | | |   +-src_unique\L50\
>
> > Qt-Utilities\fby_qt_js.dev\Form\fby_problem_widget.ui
>
> >
>
> >     | | | |   +-D:\dev\qt\qt_self_5.5.1_x64_msvc2013\qtbase\bin\uic.exe
>
> >
>
> >
>
> >
>
> > But there's no connection between moc_FcQErrorLog.o and the generated
>
> > header. It all ends with FcQErrorLog.h
>
> >
>
> >
>
> >
>
> >     | | | | +-src_unique\L50\
>
> > Qt-Utilities\fby_qt_js.dev\fby_qt_js\moc_FcQErrorLog.obj
>
> >
>
> >     | | | | | +-src_unique\L50\
>
> > Qt-Utilities\fby_qt_js.dev\fby_qt_js\moc_FcQErrorLog.cc
>
> >
>
> >     | | | | | | +-src_unique\L50\
>
> > Qt-Utilities\fby_qt_js.dev\fby_qt_js\FcQErrorLog.h
>
> >
>
> >     | | | | | |
>
> > +-D:\dev\qt\qt_self_5.5.1_x64_msvc2013\qtbase\bin\moc.exe
>
> >
>
> >     | | | | | +-src_unique\L50\
>
> > Qt-Utilities\fby_qt_js.dev\fby_qt_js\FcQErrorLog.h
>
> >
>
> >
>
> >
>
> > Thanks,
>
> >
>
> > Marco Buczilowski
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20160705/6e1d14f1/attachment-0001.html>