Re: stdcxx-13 - Windows configration (was: Re: [Fwd: notes on the stdcxx configuration process])
Hello, Martin! You wrote to stdcxx-dev@incubator.apache.org on Wed, 24 Aug 2005 06:31:39 +0400: MS Which file is vc_conf.js supposed to be the equivalent of? If it's MS one of the .config files (such as gcc.config) then I don't think MS the file is necessary at this stage unless it's generated. ?? ?? Yes, it is an equivalent of a .config file. But I do not understand ?? how it could be generated. This file specifies options for a compiler, ?? linker and librarian and I see no way to find them out automatically. MS I was hoping there would be a way to do it from within the project. MS I might have been overly optimistic. If there isn't, of if it isn't MS portable across different versions of Visual Studio (VS), the script I do not know any way to pass options used in a project to an external script. Possible way is to parce project file and get them from it but it will be definetely not portable between different VS versions. MS that generates the VS Solution and Projects (and populates the MS Configurations of each compiler with the appropriate set of compiler MS and linker options from the compiler's .config file) should also MS generate this file. However it's done it's imperative that there No, this file can not be generated. It is an origin where compiler/linker/librarian options are being taken from. May be it was just a wrong analogy with .config files (I have got an expression from makefiles that .config files play the same role). MS be one central file with the set of options for each compiler. MS Maintaining more than one would surely lead to errors. That is how it was originally organized. Compiler options where placed in the configure.wsf. However Liviu insisted on splitting options into separate files. I could return them back if needed. ?? A number of Visual Studio ?? projects shall be created for all supported Visual Studio versions. MS If you mean that they will be created by hand I fear it would be both MS too tedious and error-prone. Assuming we have three versions of VS to I can not agree. For the first time solution for VS6 could be created. All others could be obtained by autoconverting it to a new format and may be minor subsequent fixes. MS maintain (6.0, 7.1, and 8.0), each time a new test is added we will MS have to remember to update three VS Solutions and add the test to MS each one of them. Each time we decide to change a compiler option What test are you talking about? Configuration ones or unit/integration? MS common to all two or more versions of the compiler we will have to MS update two or more sets of Solutions, hundreds of projects each. MS It's important for the Solution to be able to automatically pick up MS new Projects (such as new config tests, examples, tests, etc.). It's Well, that is the problem (except config tests which are beyond the solution). MS also important that there be an easy way to add/change/remove options MS across all projects in the Solution. Could you explain why it could be need for? In a single solution it could be easily done from Visual Studio. ?? Each ?? of this projects will call configuration script as a custom build step ?? passing some parameters (like compiler name, test or debug and shared ?? or static) to it. Script will all tests and create config.h file. Than ?? build will continue to build library and other tools. MS I agree with this part. A single configuration script shared by all MS versions of VS and all compilers on Windows (except perhaps those MS targeting UNIX-like environments such as Cygwin). It should be MS possible to invoke the script independently of VS from the command MS line but it can also be included as a VS Project in the stdcxx VS MS Solution (using VS 7.1 terminology). All other Projects within the MS Solution will depend on the output of the script (the config file), MS so that building the library will automatically create or update MS the config file as necessary. But that will not work if we are going to generate solution files. ?? Your design will require running first steps ?? from a command line. MS It doesn't matter how the script is invoked, it can be made nearly MS transparent to the user (with icons, shortcuts, etc). Well, common sequence will be the following: 1) Running cmd.exe to open command line. 2) Running vcvars32.bat (or similar file to setup path and includes). 3) Running script that will configure library and produce solution file. 4) Opening solution. Only there user will be able to work with a solution. Sequence does not look completely transparent. ?? The same configuration script could be later reused ?? for compilers that can not be integrated into Visual Studio (like PSDK ?? compilers). MS 100% agreed. As I said, there should be just one general configuration MS script that either reads the contents of the original .config file or MS the contents of some preprocessed version of it spit out by the script MS that generates the Solution.
FW: [PATCH] STDCXX-11: IA64 32-bit atomic operations broken
Here is the patch for atomic-ia64-32.s: Start of src/atomic-ia64-32.s --- // // atomic-ia64-32.s // // $Id: //stdlib/4.1.1-rel/source/stdlib/atomic-ia64-32.s#1 $ // .text //.pred.safe_across_calls p1-p5,p16-p63 .psr abi32 .psr msb // extern C char __rw_atomic_xchg8 (char *x, char y); // // Atomically assigns the 8-bit value y to *x and returns // the original (before assignment) 8-bit value of *x. .global __rw_atomic_xchg8# .proc __rw_atomic_xchg8# __rw_atomic_xchg8: .prologue .body // .mfb addp4 r9 = 0, r32 // Needed to be able to dereference a 32 bit pointer ;; xchg1 r8 = [r9], r33 nop 0 br.ret.sptk.many b0 .endp __rw_atomic_xchg8# // extern C char __rw_atomic_add8 (char *x, int y); // // Atomically increments the 8-bit value *x by y and returns // the new (after increment) 8-bit value of *x. .global __rw_atomic_add8# .proc __rw_atomic_add8# __rw_atomic_add8: .prologue .body // .mmb mf addp4 r9 = 0, r32 // Needed to be able to dereference a 32 bit pointer ;; ld1.acq r15 = [r9] nop 0 ;; .add8_busywait: // .mmi mov ar.ccv = r15 add r8 = r15, r33 mov r2 = r15 ;; // .mmb nop 0 cmpxchg1.acq r15 = [r9], r8, ar.ccv nop 0 ;; // .mbb cmp.ne p8, p9 = r2, r15 (p9) br.ret.dpnt.many rp br .add8_busywait .endp __rw_atomic_add8# // extern C short __rw_atomic_xchg16 (short *x, short y); // // Atomically assigns the 16-bit value y to *x and returns // the original (before assignment) 16-bit value of *x. .global __rw_atomic_xchg16# .proc __rw_atomic_xchg16# __rw_atomic_xchg16: .prologue .body // .mfb addp4 r9 = 0, r32 // Needed to be able to dereference a 32 bit pointer ;; xchg2 r8 = [r9], r33 nop 0 br.ret.sptk.many b0 .endp __rw_atomic_xchg16# // extern C short __rw_atomic_add16 (short *x, short y); // // Atomically increments the 16-bit value *x by y and returns // the new (after increment) 16-bit value of *x. .global __rw_atomic_add16# .proc __rw_atomic_add16# __rw_atomic_add16: .prologue .body // .mmb mf addp4 r9 = 0, r32 // Needed to be able to dereference a 32 bit pointer ;; ld2.acq r15 = [r9] nop 0 ;; .add16_busywait: // .mmi mov ar.ccv = r15 add r8 = r15, r33 mov r2 = r15 ;; // .mmb nop 0 cmpxchg2.acq r15 = [r9], r8, ar.ccv nop 0 ;; // .mbb cmp.ne p8, p9 = r2, r15 (p9) br.ret.dpnt.many rp br .add16_busywait .endp __rw_atomic_add16# // extern C int __rw_atomic_xchg32 (int *x, int y); // // Atomically assigns the 32-bit value y to *x and returns // the original (before assignment) 32-bit value of *x. .global __rw_atomic_xchg32# .proc __rw_atomic_xchg32# __rw_atomic_xchg32: .prologue .body // .mfb addp4 r9 = 0, r32 // Needed to be able to dereference a 32 bit pointer ;; xchg4 r8 = [r9], r33 nop 0 br.ret.sptk.many b0 .endp __rw_atomic_xchg32# // extern C int __rw_atomic_add32 (int *x, int y); // // Atomically increments the 32-bit value *x by y and returns // the new (after increment) 32-bit value of *x. .global __rw_atomic_add32# .proc __rw_atomic_add32# __rw_atomic_add32: .prologue .body // .mmb mf addp4 r9 = 0, r32 // Needed to be able to dereference a 32 bit pointer ;;
Re: stdcxx-13 - Windows configration
Alex Ostapenko wrote: [...] ?? I am not sure that Visual Studio terminology is applicable here. ?? Visual Studio does not allow adding, removing or changing compilers ?? without writing special Visual Studio extensions. MS That's where the other script to generate the VS Solution will come MS in handy :) I am afraid that generation solutions for VS will not be an easy task itself. All VS version have different project files structures (may be except VS 7 and VS 7.1 those have similar project file format). Also, adding support for a new VS version will require significant cahnges in a script. Yes, that's understood and considered an acceptable cost given the relatively low frequency of incompatible VS releases. I think it would be better to create required project files by hands from withing an IDE and use them as they are. This will also minimize efforts on creating project files for a newer version of Visual Studio. As I said, the two big problems I see with rolling the VS Solutions by hand is the duplication of compiler and linker options between the config script and the Solution, and the tedium of manually having to add each new Project (i.e., ever new example, unit test, or locale) to the Solution. FWIW, I initially considered the manual approach as well but wound up rejecting it due to these two problems. If you can find a way to solve them I might reconsider my position. Own VS converter could be used for that purposes. That's an interesting idea that we should look into. Initially, let's focus on VS 7.1. Once we have a working prototype we can investigate the possible approaches for other versions. ?? What do you mean by extend Platform here? As I have already said ?? Visual Studio does not allow simple extension of its ?? Platform/Configuration model. MS There's no way to add a fourth Platform and beyond? There is a way MS to add another compiler, isn't there? (I sure hope so, otherwise MS we might have quite a bit more work to do than I thought). By At least no simple way. AFAIK, adding own compiler requires writing a VS add-on. Also, I have not seen any addons adding anything to Platform/Configuration options. MS extending Platform I meant adding Intel C++/Win32, Intel C++/Win64, MS and Intel C++/Win64 x64 to what's already there for MSVC. If there From reviews on the Intel site I have got an impression that only Intel C++/Win32 could be integrated into VS. x64 compiler seems to be command line only. Also, I have not seen anything about ICC for Itanium. Only for x64/EMT64. Also, I do not know how ICC 32 integrates into VS. May be it just has the same name (cl) and simply should be placed before MS cl in the path. I know they have a way to convert VS Solutions or Projects to use their compiler but I don't know the details. I'll leave it for you to investigate :) (But again, let's get a prototype working for VS 7.1 first). MS is no way to do that, we might just have to generate a different MS solution for Intel C++. That is probably what we will have to do. Please look into the single Solution approach first. If it can't be done, let's try this alternative. ?? Many teams prefer command line build for this purposes. MS So do we. Unfortunately (or perhaps thankfully), the existing Rogue MS Wave build infrastructure (RCB) is not part of stdcxx so we cannot MS rely on it. The goal of this exercise is to get both the convenience MS of the VS Solutions and Project as well as the flexibility of the MS command line, ideally in one neat package. Having VS solutions we will have command line build for free. But other compilers (like PSDK ones) will require writing special build scripts for them. Yes, that is a tradeoff, but I think it's an acceptable one. The vast majority of developers will be happy using the VS Solutions and Projects since they have the whole IDE. Developers whose development environment is the bare SDK with no IDE are, IMO, an insignificant minority (remote builds on an SDK-only target should be possible from the IDE on an IDE equipped host). That said, we will eventually have to come up with a workaround for automated testing, but let's worry about it after we're done with the IDE-based prototype. MS [...] MS By implementing the Visual Studio projects/solution, I would like MS to provide a convenient development environment for *contributors* MS to the stdcxx project. I'm less concerned with the *users* of the MS library since they only rarely build it, but if we do it the right MS way they might still benefit by being offered an example of a robust MS development framework on which they could model the development MS environment for their own applications. ?? ?? Well, that is the reason. However developers of the library could run ?? configuration script only once and then they could use a solution that ?? does not include configuration steps (Is that what you have talked ?? about in the previou e-mail?). MS My idea is that
