bugMyPaint - Bugs: bug #20406, scons --clean: creates then...

Show feedback again

You are not allowed to post comments on this tracker with your current authentification level.

bug #20406: scons --clean: creates then destroys mypaintlib_wrap.cpp

Submitted by:  Andrew Chadwick <achadwick>
Submitted on:  Fri Jan 4 14:58:55 2013  
Severity: 2 - MinorPriority: 5 - Normal
Status: ConfirmedPrivacy: Public
Assigned to: NoneOpen/Closed: Open
Release: 1.1.0 17322aebPlanned Release: None
Operating System: 

Sat Jan 5 21:32:38 2013, comment #4:

I pushed a commit which makes generate.py a proper build command: http://gitorious.org/mypaint/mypaint/commit/2bcee3f
If one really is worried about dependencies, one could wrap that in a env.AlwaysBuild().

For some reason, the header dependency detection for the Python module seems to fail when converting it into a build command. So mypaint-brush-settings-gen.h is not generated before attempted included. See attached patch.
I find this strange as in the end we just use a standard scons env.SharedLibrary builder, which I would expect to do proper dependency scanning of the headers...
Also, why creating mypaintlib_wrap.cpp later change the build order or dependency resolution of _mypaint.so ?

(file #16899)

Jon Nordby <jonnor>
Project Administrator
Fri Jan 4 19:20:54 2013, comment #3:

Well, speeding up "scons -c" a bit can't hurt.

In theory, we should tell scons all the dependencies and the build products and the build steps, and then it would also clean up for us.

In practice, this is a very tricky development task on its own, and it is easy to miss a dependency and produce outdated builds, or to forget an update when things change. The point of the whole exercise would be speed up rebuilds during development.

Some of our build steps with complex dependencies (like generate.py and swig) take so little time that I consider it a waste of developer ressources to write and maintain a proper build rule for them.

Martin Renold <martinxyz>
Project Administrator
Fri Jan 4 16:17:48 2013, comment #2:

Dumping info from IRC:

<Sebastinas> achadwick: scons -c also runs python generate.py and deletes the generates files after that.
<Sebastinas> achadwick: I haven't doing anything with scons for ages but this looks interesintg: http://www.scons.org/wiki/GenerateConfig

Andrew Chadwick <achadwick>
Project Administrator
Fri Jan 4 15:34:07 2013, comment #1:

Straightforward way -- check if scons is invoked with '-c' via env.GetOption('clean') [attach #1] and skip creation of mypaintlib_wrap.cpp in that case

(file #16896)

Libra Rian <zrzz>
Fri Jan 4 14:58:55 2013, original submission:

Confirmed by Sebastinas on OFTC during a debian packaging review. "scons -c" in its simplest case (running on an already clean tree) regenerates mypaintlib_wrap.cpp each time, only to destroy it later in the very same command:

The same is true when running on a built tree, of course.

This appears to serve no purpose. Is it possible to have scons -c not do this?

Andrew Chadwick <achadwick>
Project Administrator


Attached Files
file #16896:  clean.diff added by zrzz (749B - text/x-patch)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -unavailable- added by jonnor (Updated the item)
  • -unavailable- added by martinxyz (Posted a comment)
  • -unavailable- added by zrzz (Updated the item)
  • -unavailable- added by achadwick (Submitted the item)

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.


    Error: not logged in



    Follow 2 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sat Jan 5 21:32:38 2013jonnorAttached File-=>Added 0001-build-Use-a-scons-Command-to-build-Python-module-_my.patch, #16899
    Fri Jan 4 15:34:07 2013zrzzAttached File-=>Added clean.diff, #16896
    Show feedback again

    Back to the top

    Powered by Savane 3.1-cleanup