libcdio-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Libcdio-devel] should libcdio be declared 0.91 as is or with furthe


From: Pete Batard
Subject: Re: [Libcdio-devel] should libcdio be declared 0.91 as is or with further changes ?
Date: Tue, 22 Oct 2013 20:11:13 +0100
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1

Hi Natalia,

On 2013.10.21 22:52, Natalia Portillo wrote:
Do you have knowledge of VS precompilation scripts?

And postcompilation?

I've done some very limited work with Pre and Post build events in VS2012 for libwdi, where I wanted Intellisense to avoid scanning a large autogenerated include (to stop it from hogging the CPU when doing so), as well as execute the host-build executable that generates that include.

You can take a look at the PreBuiltEvent and PostBuildEvent from [1]. The Pre task runs the following set of commands before the build:

cd $(ProjectDir)\..
if exist embedded.no_is ren embedded.no_is embedded.h
embedder embedded.h

Basically, it uses one of the various project variables, here $(ProjectDir), to switch to the source directory, then renames a file and finally calls on a previously generated executable (embedder.exe) to updates the embedded.h include

I think the more troublesome part is figuring out the various variable names that Visual Studio makes available, as the rest is equivalent to writing a batch file.

We are having problems on how to make the work that usually autoconf does, and 
how to auto run test once compiled.

Hopefully the above will help.

In your case, in the Post task, you probably want to 'cd' to the directory that contains the generated test executables (I think there's an MS variable for the build dir), then check if the test executable exists before launching it.

I believe that the DOS errorlevel generated by any command from these scripts is used by the Pre/Post step to determine if the operation was successful, and flag an error if it wasn't.

There may also be other ways to run a test suite within Visual Studio.

Also i need to get it to create a dynamic library not just the static one as it 
is doing, but this is not so much of a priority.

I don't have a good answer to that one. Right now, in the Visual Studio projects I have, that create a library, I maintain two MSVC projects: one for the static library and one for the DLL.

For instance, if you look at libwdi [3], you'll see a libwdi_dll.vcxproj and a libwdi_static.vcxproj. The global MSVC solution is set to only use one of those (in this case the static), leaving the user to generate the DLL manually, if they need it.

Still, I wouldn't mind finding a solution, that doesn't involve manually keeping 2 project files in sync (and that isn't based on using CMake, as the requirement of CMake to run on a platform with the target MSVC installed, just to generate a project file compatible with that target, is too restricting on cross-platform projects, where a maintainer using Linux may want to generate a set of ready-to-use static MSVC project files for a release)...

Regards,

/Pete

[1] https://github.com/pbatard/libwdi/blob/master/libwdi/.msvc/libwdi_static.vcxproj#L141
[2] http://www.robvanderwoude.com/errorlevel.php
[2] https://github.com/pbatard/libwdi/tree/master/libwdi/.msvc




reply via email to

[Prev in Thread] Current Thread [Next in Thread]