Simple batch build

[pvonkaenel]

I make frequent modifications to a shared library and then build both Debug and Release builds.  Is there a way I can setup a macro to build the solution for both the Release and Bebug builds?  I'm currently using    _project_command2('build solution');  in a macro to build the solution and link it to a hot key.

Thanks,
Peter

[pvonkaenel]

Never mind.  I think I came up with a macro that works.  Does this seem like a reasonable solution?

Code: [Select]

_command void build_sln_allcfg() name_info(','VSARG2_MARK)
{
    ProjectConfig cfgList[]; // All available configurations
    _str cfgName;            // Current configuration
    int associated;

    getProjectConfigs(_project_name, cfgList, associated);
    cfgName = getActiveProjectConfig();
    for (i=0; i < cfgList._length(); i++) {
        project_config_set_active(cfgList[i].config);
        _project_command2('build solution');
    }

    project_config_set_active(cfgName);
}

Peter

[Dennis]

Here are a couple other options.

1) workspace with multiple projects -- define an umbrella project and set it's dependencies to require that it's build depends on all the other projects and all configurations.

2) workspace with just one project -- define an umbrella configuration (DebugAndRelease) and set it's Build tool to (in the advanced options dialog of Project Propertiies > Tools) to do a Call Other Tool to build both Debug and Release.

3) either case -- define an umbrella "BuildAll" tool that uses "Call Other Tool" to call the Build tools for both configurations.

[pvonkaenel]

Is the umbrella project something that exists in the vcproj file or in a Slickedit file?  I'd rather not change the vcproj since there are many people working in it and I'm the only one using Slickedit.

Peter

[Dennis]

All those techniques are for SlickEdit projects.  I didn't notice that your were talking about Visual Studio workspaces.  In that case, you are probably go have to stick with your solution, unless you can figure out how to make devenv build both configurations from the command line and add a BuildAll tool that does that.

[Matthew]

If your solution only contains .vcproj files, then you can replace the "stock" devenv call with a call to vcbuild.exe. vcbuild gives you the option to build all configurations.
If you have mixed .vcproj and .vbproj/.csproj in your solution, then you'll have to stick with either devenv.exe or msbuild.exe, which I believe only allow you to build 1 config.

[Dennis]

And then there is the low tech solution.  Add a Project Build Tool named "BuildAll", and make it issue builds for both configurations, as follows:

Code: [Select]

devenv "%w" /build Release /project "%rm" /projectconfig "Release|Win32" & devenv "%w" /build "Debug" /project "%rm" /projectconfig "Debug|Win32"

[pvonkaenel]

Thank you for all the helpful solutions.  It's always amazing to see how many possible ways there are to working around a problem.

Unfortunately my VS2005 sln does contain a mix of vcproj and csproj projects, so I cannot switch to vcbuild.  So far I'm getting use to the macro I wrote, but if it end up being a headache, I'll create the BuildAll Build Tool.

Thanks again,
Peter

[hs2]

One more hint regarding the fancy error markers in case you'd like to see them after your batch build finishes.
See http://community.slickedit.com/index.php?topic=1423.msg6007#msg6007
In your case you could simply add the

echo <binary 1>serr

at the end. The 'serr' command should at least contain   

Code: [Select]

set_error_markers();
refresh('A');to make sure that the error markers are shown.

HS2

Edit: More details about macro injection from ext. batch: http://community.slickedit.com/index.php?topic=819.msg3577#msg3577.
I think you shouldn't use 'devenv ... & devenv & echo <binary 1>serr' b/c it won't be called in case of the prev. devenv call returns an error

[Dennis]

I know HS2 is gonna hate this, but that \1 "feature" is something that is going to go away in the future.  I promise you that.  So, I do not recommend anyone else to build up tools relying on that horrid mechanism.

Why must this "feature" go away?  It is flat out dangerous.  For example, let's say, in the build window, you do a "grep" through some files for a string, and accidently search through some object files or executables.  There's a pretty good chance some of them will have ascii 1 in there, and slickedit is going to try to execute whatever "command" follows.  This is fairly innocuous, since usually the text will not be a valid command, but what if the text immediately following the \1 is "del *.*".

We make every effort to maintain backward compatibility with our API's and how SlickEdit works release to release, but some places, you have to draw the line.

[hs2]

Hi Dennis,

I don't have any concerns if this 'feature' (and I know that's more a evil hack than a robust feature) is removed in the future as long as there is a (better) replacement for it.
In other words a mechanism to have error parsing incl. markers (sync'd) to a concur_command.
Well, at least the build subsystem should have a more generalized '_post_build' handling. But I'm sure you know what's needed to make quite a lot of us happy

HS2