CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Results 1 to 5 of 5
  1. #1
    Join Date
    Jun 2002
    Location
    Germany
    Posts
    1,557

    [RESOLVED] Using VC++ non-Win embedded environments

    Hello,

    My name is Chris and my career function is software development manager in the automotive industry. We are specialized in development of real-time control software for microcontroller applications as well as PC-based applications.

    We use Visual C++ for 'normal' projects. In addition, we use Visual C++ to manage real-time control projects for microcontroller applications. These are not WinCE projects, but rather projects using hand-written operating systems for 8-bit through 32-bit architectures written in C, C++ and a small bit of Assembler. We have been doing this for well over 10 years and it works very well. We use VC++ in combination with GNU make. The compiler / linker / assembler calls are hand-written in GNU makefiles. The projects are of type 'External Makefile'. We handle the dependencies with analysis commands using Unix tools such as AWK and SED.

    I would like to know if this kind of 'non-traditional' usage of Visual C++ will be supported in the future. In addition, I would like to ask if you have ever heard of others who use VC++ to manage real-time microcontroller applications.

    One problem we have is the amount of effort which it takes to set up a new project. There is no kind of wizard support.

    Do you actively work on this kind of support? For example, I could imagine a support for some kind of generic external compiler / linker call which need not be explicitly entered for each source file, but rather a project-wide setting. This might make it possible to handle the header and time-stamp dependencies within VC Studio. Also it would allow for a more uniform treatment of projects, no matter what kind of exotic compiler tool-chain is to be used. Here I am thinking of the kind of integration support which Intel has written for their tool chain.

    A more generic interface to the the browser facility for external makefile projects would also be very useful?

    Have you ever considered implementing any kind of support for GNU make in addition to the make facility which is (or at least was) based on NMAKE?

    Thank you for your insights and information on this topic.

    Sincerely, Chris.
    Last edited by dude_1967; June 22nd, 2006 at 03:07 PM. Reason: Improved clarity of questions
    You're gonna go blind staring into that box all day.

  2. #2
    Join Date
    Jun 2006
    Posts
    17

    Re: Using VC++ non-Win embedded environments

    We don't have any plans right now to provide infrastructure in Visual Studio to support C++ development targeting non-Microsoft platforms. It's funny you ask, because I actually had a conversation with someone about this kind of thing this morning, but there are definitely no product plans in this regard.

    Thanks,

    Steve Teixeira
    Group Program Manager
    Visual C++

  3. #3
    Join Date
    May 2006
    Posts
    13

    Re: Using VC++ non-Win embedded environments

    As Steve mentioned, we have no plans for this. I'd just like to confirm that support for "External Makefile" project types in the IDE will definitely stay, though.

    Thanks,
    Tarek Madkour
    Lead Program Manager
    Microsoft Visual C++
    Tarek Madkour
    --
    Lead Program Manager
    Microsoft Visual C++

  4. #4
    Join Date
    Jun 2006
    Posts
    3

    Wink Re: Using VC++ non-Win embedded environments

    Quote Originally Posted by dude_1967
    We use VC++ in combination with GNU make. The compiler / linker / assembler calls are hand-written in GNU makefiles. The projects are of type 'External Makefile'. We handle the dependencies with analysis commands using Unix tools such as AWK and SED.

    [ ... ]
    One problem we have is the amount of effort which it takes to set up a new project. There is no kind of wizard support. [...] I could imagine a support for some kind of generic external compiler / linker call which need not be explicitly entered for each source file, but rather a project-wide setting. This might make it possible to handle the header and time-stamp dependencies within VC Studio. Also it would allow for a more uniform treatment of projects, no matter what kind of exotic compiler tool-chain is to be used.
    To add a lob in from the bleachers to what Steve and Tarek have already provided, I must say I love what you are doing. This strikes me as a perfect adaptation of Visual C++ 2005 Express Edition (with some careful squinting at the terms of use). Since the Express Editions are plug-in challenged, customization would have to be done by making private project and item templates (and perhaps configurations) to facilitate your build scenarios. Now that .proj files are XML, there are other opportunities with regard to co-opting MSBuild as well, depending on whether it's general-purpose enough for your needs.

    Also, have you looked at the provisions for Visual Studio Extensibility that can be used with the commercial VS 2006 versions? Check out http://msdn.microsoft.com/vstudio/extend/ There's even a minimal-cost redistributable IDE that can be used as a holder for custom plug-ins (I think XNA uses something like that for some game development workflow kits when VS is not installed). I'm not sure what your business case might be for going that far but it strikes me as worth a look.

  5. #5
    Join Date
    Jun 2002
    Location
    Germany
    Posts
    1,557

    Re: Using VC++ non-Win embedded environments

    Thanks tarekmadkour and steixeira for taking the time to answer and providing additional information.

    Please note that we really appreciate the quality of your development environment. So much so that we, in fact, go to great lengths to use Dev Studio and VC++ for ALL of our multi-platform cross-developments, including Win32 Console and MFC applications as well as external microcontroller applications.

    We will continue using projects of type 'External Makefile' for future developments.

    Also we will continue benchmarking the project interfaces and examining options such as those mentioned by orcmid.

    Sincerely, Chris.
    You're gonna go blind staring into that box all day.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  





Click Here to Expand Forum to Full Width

Featured