msvs_prebuild and msvs_postbuild for MSBuild, again

[Stefan Haller]

I'd like to raise the issue of supporting msvs_prebuild and
msvs_postbuild in the MSBuild-based generator again.

Our build system currently generates only VS 2008 project files, and it
uses msvs_prebuild and msvs_postbuild; this is working well for us. We
can't easily switch to VS 2010 or 2013 because msvs_prebuild and
msvs_postbuild are not supported there.

This has been discussed before, e.g. here:

<https://groups.google.com/d/msg/gyp-developer/GGQj0YsP148/25j4Gb1Da0wJ>

The consensus seems to be that prebuilds and postbuilds are bad, and
actions should be used instead. However, in our case actions are not a
viable substitute, as far as I can see:

1) For the prebuild-steps, our requirement is that they only run when a
target gets built. We have a long dependency chain of dependent
targets, and when making a change to a target close to the end of the
chain, it's important that only that target and its dependents have
their prebuild steps run; otherwise, do-nothing builds would be much
too slow. I don't see how to achieve this with actions.

2) Our postbuild step needs to run after the target is linked, so an
action doesn't work (it runs before the target's source files are
compiled, see
<http://msdn.microsoft.com/en-us/library/e85wte0k.aspx>). The perfect
solution for us would be a custom build step on the project, but gyp
doesn't seem to support these, as far as I can see. A post-build
event is the next best solution, then.

The suggestion to solve this with an action in a dependent none-type
target doesn't work well, because setting that target as the StartUp
Project in Visual Studio requires extra configuration; and in Xcode
there's no way at all to debug such a target. (Again, the 'postbuild'
feature of the Xcode generator solves this perfectly for us.)

In short, my plea would be to accept the patch from
<https://codereview.chromium.org/8229003/>. We are doing this locally,
and it solves all our problems; I'm just worried that it might break in
the future.

Thanks,
Stefan


--
Stefan Haller
Berlin, Germany
http://www.haller-berlin.de/

[Stefan Haller]

Ping.

Any opinions, anyone?

Thanks,
Stefan

[TJ Grant]

You can chain targets together to get pre-build and post-build effects.

I've not extensively post-builds with MSVS but I've done it myself at least once.

I'd suggest not using the built-in pre-build and post-build variables specific to MSVS.

Instead, you'll want to set up your GYP like this:

'targets': [

{

'target_name': 'mybuild_pre',

'type': 'none',

'actions': [

{

'action_name': 'Prebuild Action',

'inputs': [ '../../abc/Testbed/abc/PrebuildData.txt', ], # inputs

'outputs': [ '../../dummy', ], # outputs

'action': [ 'whatever.exe', '<@(_inputs)', '--option', 'whatever', ], # action

},

], # actions

},

{

'target_name': 'mybuild',

'product_name': 'mybuild',

'type': 'executable',

'sources': [

'../../source/Testbed/abc/mybuild.cpp',

'../../source/Testbed/abc/mybuild.h',

], # sources

'dependencies': [

'mybuild_pre'

], # dependencies

'include_dirs': [

'../../source/Testbed/abc',

], # include_dirs

},

{

'target_name': 'mybuild_post',

'type': 'none',

'actions': [

{

'action_name': 'Postbuild Action',

'inputs': [ '../../abc/Testbed/abc/PostbuildData.txt', ], # inputs

'outputs': [ '../../dummy', ], # outputs

'action': [ 'whatever.exe', '<@(_inputs)', '--option', 'whatever', ], # action

},

], # actions

'copies': [{

'destination': '/Volumes/Lab/tools/', # destination

'files': [ '../../build/<@(OS)/debug/abc', ], # files

}], # copies

'dependencies': [

'mybuild'

], # dependencies

}

], # targets

When you build, set "mybuild_post" as your "startup project" and build that directly

Targets will be easier to manage if you put them in separate .GYP files and include them.

Best regards,

--TJ Grant

tjg...@tatewake.com

--

---
You received this message because you are subscribed to the Google Groups "gyp-developer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gyp-develope...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Stefan Haller]

Thanks; I'm aware of these techniques, and we are using them in several
places in our build system. We can't use it for everything though, for
reasons that I explained in my initial mail.

Your proposed solution has these problems:

1) mybuild_pre runs for every build, even for targets that wouldn't
otherwise be built. This makes incremental builds prohibitively
expensive.

2) mybuild is the target that you need to select if you want to debug
it, so if you rely on the IDE to build the selected target if it's out
of date, the postbuild won't run. Debugging mybuild_post is possible
too, but requires extra configuration work for each developer.

Thanks,
Stefan

[Scott Graham]

On Sun, Dec 22, 2013 at 2:57 AM, Stefan Haller <li...@haller-berlin.de> wrote:

I'd like to raise the issue of supporting msvs_prebuild and
msvs_postbuild in the MSBuild-based generator again.

Our build system currently generates only VS 2008 project files, and it
uses msvs_prebuild and msvs_postbuild; this is working well for us. We
can't easily switch to VS 2010 or 2013 because msvs_prebuild and
msvs_postbuild are not supported there.

This has been discussed before, e.g. here:

   <https://groups.google.com/d/msg/gyp-developer/GGQj0YsP148/25j4Gb1Da0wJ>

Hah, apparently I wanted them back then too. I repent and agree that they're a bad idea.

Is it definitely not possible to specify correct input and outputs, rather than using an always-run? Worrying about incremental build times without fixing that first seems like barking up the wrong tree.

Assuming not, I guess the patch is "ok", except that it needs to be updated to do something in the ninja generator (at least warn that it's not implemented).

 

Thanks,
   Stefan

--
Stefan Haller
Berlin, Germany
http://www.haller-berlin.de/

[Stefan Haller]

Scott Graham <sco...@chromium.org> wrote:

> Assuming not, I guess the patch is "ok", except that it needs to be
> updated to do something in the ninja generator (at least warn that it's
> not implemented).

OK, I could try to work on that if I can find some time. I suppose this
just needs some added code in MsvsSettings.__init__ (in
msvs_emulation.py)?

I would appreciate some guidance as to how to write a test for this, and
where to put it.

Of course, if anybody else feels like jumping in and doing the work, I
wouldn't mind either. :-)

[Bradley Nelson]

Some more context for what it's worth.

msvs_prebuild / msvs_postbuild were supported for the transition off checked in project files (which had a few cases that used them).

When jeanluc started adding msbuild support, we talked about whether msvs_prebuild / msvs_postbuild equivalents should be supported for msbuild. At the time chromium, no longer used them (as when other platforms were taken into account they were not a good choice), so we opted out of supporting them.

Chaining can be tedious, but is the only thing that works cross platform.

That said, as all the msvs_* / msbuild_* options are all generator specific, I have no objection to them being supported assuming the ninja generator at least makes noise about it.

-BradN