[Scons-dev] Scons-dev Digest, Vol 56, Issue 3

Left Right olegsivokon at gmail.com
Mon Sep 12 17:59:17 EDT 2016


Sorry, I know this is old, but after trying a few things... I still
cannot find the place where your code checks if outputs are up to
date.

Below is the minimal example of what I tried based somewhat on
SCons.Python.Value.

import subprocess
import os
import SCons.Node

def exists(env):
    return subprocess.call("command -v docker") == 0

def docker_build(target, source, env):
    copy = os.environ.copy()
    # do some stuff with environment
    docker_file = source[0].path
    ctx = source[0].get_dir().path
    out = subprocess.check_output(
        ["docker", "build", "--no-cache=true", "-q", "-t", tag, "-f",
docker_file, ctx],
        env = copy)
    # some more stuff with output

class DockerImage(SCons.Node.Node):
    # here I'm lost

def generate(env):
    env["BUILDERS"]["Docker"] = env.Builder(
        target_factory = DockerImage,
        action = env.Action(
            docker_build,
            lambda t, s, e: "docker build: %s" % s[0].path))


I've overloaded every method I could find from Node, Base, File and
Dir. The only method that get's called is the builder_set() - which
does nothing valuable. However, if I make this an input node rather
than output, then changed_since_last_build() does get called...  I
know that Executor is created for this builder and I know that
__call__() of this builder is called just the same way any other
builder would.  But it's impossible to find why anything is called or
when and what the expected result should be.  I'd expect this to give
an error, or to ignore the setting - instead, if I don't set
target_factory - the builder always runs, and if I don't, then the
builder always acts as if it is up to date.

Bottom line: how do I implement "outputs up to date" check?  I don't
care if it's a lot of work, I just need something / someone to explain
what makes this check.

TIA.

On Fri, Aug 5, 2016 at 8:43 AM,  <scons-dev-request at scons.org> wrote:
> Send Scons-dev mailing list submissions to
>         scons-dev at scons.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://pairlist2.pair.net/mailman/listinfo/scons-dev
> or, via email, send a message with subject or body 'help' to
>         scons-dev-request at scons.org
>
> You can reach the person managing the list at
>         scons-dev-owner at scons.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Scons-dev digest..."
>
>
> Today's Topics:
>
>    1. Builder with custom decider and non-file based target (Left Right)
>    2. Re: Builder with custom decider and non-file based        target
>       (Dirk B?chle)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 4 Aug 2016 14:55:21 +0300
> From: Left Right <olegsivokon at gmail.com>
> To: scons-dev at scons.org
> Subject: [Scons-dev] Builder with custom decider and non-file based
>         target
> Message-ID:
>         <CAJQBtgmsKwA_HiYGnWh=ZsWapC2F4A4VNSX3-U_eurL_ybJWoA at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hello list.
>
> I'm trying to come up with a builder for Docker images. Docker images
> are built based on a Dockerfile template and a bunch of other sources
> one way or another related to the template. The output, however, isn't
> a file strictly speaking. The builder should combine two Docker
> operations: build+push, thus the final build artifact is the image
> residing in Docker registry (a server with it's own database,
> accessible via HTTP).
>
> What I'd like to accomplish is the following:
> 1. Create Docker Builder s.t. given the Dockerfile and other auxiliary
> files will call "docker build", then "docker push" to produce the
> build artifact and to put it in the Docker registry.
> 2. Prevent building images if a query to Docker registry for a
> previously built image succeeds.
>
> I'm now looking at target_factory of SCons.Builder, but I'm not sure
> this is the way to proceed. Please advise.
>
> Thanks.
>
> Oleg
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 4 Aug 2016 18:56:26 +0200
> From: Dirk B?chle <tshortik at gmx.de>
> To: scons-dev at scons.org
> Subject: Re: [Scons-dev] Builder with custom decider and non-file
>         based   target
> Message-ID: <57A373BA.8030703 at gmx.de>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> Hi Oleg,
>
> On 04.08.2016 13:55, Left Right wrote:
>> Hello list.
>>
>> I'm trying to come up with a builder for Docker images. Docker images
>> are built based on a Dockerfile template and a bunch of other sources
>> one way or another related to the template. The output, however, isn't
>> a file strictly speaking. The builder should combine two Docker
>> operations: build+push, thus the final build artifact is the image
>> residing in Docker registry (a server with it's own database,
>> accessible via HTTP).
>>
>> What I'd like to accomplish is the following:
>> 1. Create Docker Builder s.t. given the Dockerfile and other auxiliary
>> files will call "docker build", then "docker push" to produce the
>> build artifact and to put it in the Docker registry.
>> 2. Prevent building images if a query to Docker registry for a
>> previously built image succeeds.
>>
>> I'm now looking at target_factory of SCons.Builder, but I'm not sure
>> this is the way to proceed. Please advise.
>>
>
> SCons works file-centric, meaning it expects that input and output to the single Builders (build steps) are actual files. So, as
> soon as you try to manage your images "proxy-wise" on a remote server you'll run into problems.
> There is probably no easy workaround and you have to code the "remote" functionality in Python directly...
>
> Best regards,
>
> Dirk
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Scons-dev mailing list
> Scons-dev at scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>
> ------------------------------
>
> End of Scons-dev Digest, Vol 56, Issue 3
> ****************************************


More information about the Scons-dev mailing list