Hi Pete, El 22/10/2013, a las 20:11, Pete Batard <[email protected]> escribió:
> 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. I’ll check about it this weekend. >> 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)… > Yes I expected to need another project. I’m worried what will happen when a new file.c is added to the project on the UNIX side, as probably no one will care to add the same file to the vcxproj file (just a plain XML, indeed I made them all outside of VS), and will get out of sync again. For the rest of the 0.91, wait! I’ve been heavily working monday and tuesday, with a friend that wants to stay anonymous, and we have almost corrected the Mac OS X driver, and found a bug in the inner guts of libcdio. Right now if you call get_devices() or get_default_device() it is making an open() on the drive, library-wide. Not so much of a problem in Linux or Win32, but opened drives in Mac OS X disappear from the list of available drives, so anything that comes later than the get() functions will fail in Mac OS X. As I understood it, get() functions should merely get a list of available drive paths, not open any of them at all, or even init the drive, so this should be corrected, isn’t it? Regards, Natalia Portillo
