Compiling for Windows

Help
jim_monte
2006-04-11
2013-04-22
  • jim_monte

    jim_monte - 2006-04-11

    Hi,

    I would be interested in a Windows version of
    BRL-CAD.  From what I have read, such a thing
    is close to existing.  I have even found an
    installation package with a beta version, but
    it required a key to install.  I noticed that
    CVS for BRL-CAD has non-developer and
    developer versions.  Which of these would be
    better to use as a basis for Windows version?
    And if the developer version is the one, how do
    I get a developer name/password?

    To save someone from warning me, I am aware of
    the risks, etc. associated with using beta
    software.  I also have enough experience with
    low level Win32 programming that I should be
    able to debug after a crash to help test the
    software.  Thanks for any information.

    Jim Monte

     
    • jim_monte

      jim_monte - 2006-04-14

      I today found the installable version and source
      with MS VC7 files was just released shortly after
      I posted.  Installation was clean, and it
      at least starts OK.  I did not look at it much
      further yet, but I did notice that the ray
      tracing does not work in the main window.  I
      also found some doc, again I did not look through
      all of it yet so I do not know how thourough it
      is, but I did see a note about the ray tracing
      not being fully supported in Windows yet.  Ray
      tracing in a separate window worked OK, but it
      used a lot of CPU after the drawing was done when
      rt was not doing anything.  I am trying to
      compile now to see how that goes.

      Jim

       
      • jim_monte

        jim_monte - 2006-04-17

        Hi All,

        The compile did not go well.  Based on the
        project names, "all" seemed a likely candidate
        to build.  But "all" did not have much in it.
        The next most likely one was brlcad.  Using the
        options as supplied, I got over 200 warnings
        and errors, some of these fatal.  Looking at the
        fatal errors, libraries are not being found in
        the link phase.

        Taking another approach and trying to start
        simple and work up from there, I started with
        libz since I have worked with zlib before.
        It compiled with only a few warnings that are
        easy enough to fix, but again at the link phase
        it could not find file tcl84_d.lib.  Since
        there was a project called libtcl, it appeared
        that this was just a dependency issue.  Project
        libtcl compiled and linked with only a link
        warning related to the options specified.  One
        of its output files was tcl84_d.lib and it had
        a post-build step to copy files.  So I expected
        the libz build to now work just fine.  But it
        gave the same error about the library.

        It would seem that something is wrong with these
        project files.  Is there a better set to use?
        Also, is a VC6 version of the project files
        available?  The .NET studios have a lot of space
        eaten up by various menus and buttons sprinkled
        around so I just prefer using VC6 if possible.
        VC7 can read VC6 projects, but a VC7 project is
        useless for VC6.

        Curious in general and interested in why the
        ray tracing did not work in the main window,
        I looked through a few of the source files, and
        noticed some issues with the Win32-specific
        code.  These seem more appropriate for the
        developers forum, so I will post them there.

        Jim

         
        • jim_monte

          jim_monte - 2006-04-18

          Strangely, all of the post-build steps
          intended to copy the output files to a common
          location were incorrect.  After fixing these
          in each of the projects, there were no errors.
          There were still just over 200 warnings, but
          most did not seem dangerous.  Nearly all of
          them were either due to incomplete function
          declarations, unused variables, or implicit
          type conversion.  I fixed a few, although I
          have more interest at the moment in seeing the
          program run. There were a few warnings that did
          concern me since they involved uninitialized
          variables, but I have not looked into this
          much yet.  At this point I have started mged,
          which means at least that all static libraries
          and those loaded with the program were resolved.

          If there is any interest in getting a copy
          of the working project files, let me know.
          They require version 7.1 of Visual Studio.
          Version 7.0 (the original .NET) does not
          accept them.

          Jim

           
          • jim_monte

            jim_monte - 2006-04-20

            Hi All,

            I may have been a bit premature writing that
            the project works.  The compiles and links are
            all OK, but running in a debugger fails during
            initialization.  It appears that Tcl/Tk is not
            finding something.  Unfortunately, I know little
            about Tcl/Tk, so this probably will require me
            to step through the initialization very slowly
            to see where the problem is.

            Looking further ahead, I probably would be
            happier with a native Windows gui for both
            aesthetics and performance, so it may not
            be such a bad thing to see what Tcl/Tk is doing.

            I have eliminated about half of the warnings
            generated during compilation.  My latest total
            (at default warning level 3) is a bit under 100.
            A few of the warnings that I fixed were actually
            errors.  Is there some process to submit the
            changes to see if anyone wants them?  At first,
            I was carefully initializing the changes in
            comments, but after a while this started to
            become too much work due to the sheer number of
            lines changed.

            Jim

             
            • Sean Morrison

              Sean Morrison - 2006-05-20

              I am similarly concerned at the quantity of unchecked changes that you are accruing.. :-)  When you get a chance, please post up a patch of some of your changes so they can be reviewed or even better, stop by the IRC channel so we can discuss how to possibly make this a whole lot easier.  Direct access is always possible for someone like yourself that sustains a high level of interest, but seeing an initial patch is a necessary first step.

              The channel is #brlcad on irc.freenode.net, i.e. the Freenode network.  If you've never used IRC, it's basically live group discussions where you join channels that focus on particular topics.   The Freenode network that BRL-CAD lives has a large software development following with just about every major open source software represented.  There are more details on http://irchelp.org for getting a binary client and connecting.  Some popular irc clients are xchat and irssi.

               
              • jim_monte

                jim_monte - 2006-05-23

                Sean,

                I think we both agree that the number of
                changes I have made is getting large and
                merging with existing CVS source will become
                increasingly difficult as they grow.  So I will
                complete the changes I am in the process of
                making, test them, and then look into how to
                submit the changes.

                A summary of the changes I am working on or
                have completed follows.

                - Elimination of compiler warnings from the
                  Windows build.  There are 4 remaining that I
                  have intentionally left to look at more after I
                  understand the overall package better.

                - Consistent const char **argv for TCL functions
                  and function pointers.  This change followed
                  from the compiler warnings.  A few may still
                  be hiding somewhere, but this is essentially
                  done.  This was mostly accomplished by adding a
                  huge number of const keywords, in the
                  prototypes, definitions, and variables that
                  referencing the stings being passed.
                  However, there were a few instances
                  where the strings were really changed.  In all
                  but one case, I did this the "right" way,
                  reworking the functions to leave the strings
                  alone instead of adding the overhead of an
                  allocate + copy.  In that last case, there was
                  what seemed to be an unlikely situation that
                  was much easier to handle by making a copy.

                - New timing facilities for Windows.  The
                  replacement uses QueryPerformanceCounter()
                  and QueryPerformanceFrequency() for elapsed
                  time and GetProcessTimes() for kernel and
                  user times.  The change should be transparent
                  to the caller, except for getting the right
                  times.

                - libbu modifications
                  - A winutil file for utilities to work with
                    Windows.  This file currently has only a
                    single function to change the '\' characters
                    in a Windows path specification to the '/'
                    characters used in Unix.  This function
                    was created because I noticed this conversion
                    being done frequently with the same code
                    copied and pasted.  I made it general in that
                    it can accept a size for the converted string
                    so it need not be null terminated and returns
                    the size of the string since that information
                    can essentially be found for free and may
                    be of use to the caller.  The ability to
                    work with strings lacking a null termination
                    can be useful for both performance reasons
                    and to allow a string to remain a
                    const char *.  I generally perfer to keep
                    track of string sizes myself to avoid things
                    like strlen().

                  - enhanced bu_bomb() to allow variable
                    arguments in message.

                  - bu_vls upgrades.  I noticed that in a
                    significant number of instances, the vls
                    facility is used to build a small string
                    that is then discarded.  With the current
                    version, this will always require an
                    allocation and free.  To avoid this, a small
                    buffer was added to the end of the existing
                    structure, and the init call points the
                    string pointer to this buffer.  The remaining
                    bu_vls functions were modified to make
                    the change transparent to callers of bu_vls.
                    While making the changes, I noticed that
                    the bu_vls_trimspace function was implemented
                    inefficiently with multiple function calls to
                    process a single character.  So this funciton
                    was rewritten as well.
                - Improved efficiency in help messages.  The
                  few instances I had mentioned where the
                  bu_vls facility was used to create a copy
                  of a string that does not change were
                  only the tip of an iceberg.  I am under water
                  now getting to the bottom.  I have also
                  reformatted to some extent when making these
                  changes to conform with the coding standards
                  given because I had the alternatives of putting
                  in fixes that did not conform with the
                  standards, adding code that did conform that
                  was surronded by non-conforming code so that
                  it looked wrong, or fixing the wole thing to
                  conform.  The conventions followed were as
                  in HACKING with two additions that I prefer.
                  Braces are always used to group loops and
                  ifs, with the exception of "else if".  This
                  eases debugging and reduces the chances of
                  errors when another line is added to existing
                  code.  Finally, the code is limited to a line
                  length of 80 characters, treating the tabs as
                  if they had their expanded size.  This is
                  easier to read than lines wrapping around
                  and makes an occasional printing look much
                  better.

                - Occasional efficiency improvements.  One I
                  recall offhand is replacing something like
                  if (strlen(s) == 0) with if (*s == '\0') to
                  avoid the function call, which is doing noting
                  useful once it finds that the length is at
                  least 1.

                - Project file fixes.  There were problems
                  with the dependencies that caused a linker
                  warining that was strange and difficult to
                  identify.  Also the post-build steps were
                  improved to echo information to the console
                  and to conditionally rebuild the destination
                  directories if they do not exist.  One
                  additional thing I want to do in this iteration
                  is to separate the intermediate files (.obj,
                  etc. residing in directories Debug and
                  Release) into their own directory.  This will
                  keep the directories holding the project
                  files clean, which will make it easier to move
                  the project from one computer to another.

                - Others?  I must be forgetting something here...

                No, I have never used IRC.  I will have to
                look into that.  I guess I still think in
                batch mode.  BTW, I still am not sure what
                the differences between the Open Discussion
                and Help forums are since all the posts seem to
                be asking for some type of help, but replies to
                this message probably belong in the Developers
                forum, so I will look there.

                Jim

                 
                • jim_monte

                  jim_monte - 2006-05-30

                  I thought of a few more changes, but I will
                  transfer this to the Developers forum and
                  continue it there.

                  Jim

                   
        • jim_monte

          jim_monte - 2006-04-24

          Hi,

          Regarding the VC6 project files I was asking
          about, I made my own.  So far it is just for
          a debug version, but adding a release build
          should be substantially less work.  Essentially
          this was a manual translation with a text
          editor and the Version 7.10 files, so it took a
          while to do.  I did not include the "all" project
          since Visual Studio has features like "Rebuild
          All" to do a full build.  Prior to .NET, Visual
          Studio offered an "Export to Makefile" option,
          so the VC6 project files could be useful to
          for working without the IDE.

          I noticed two frequently defined but never
          used macros, __win32 and _WINDOWS.  I did not
          include these in the project files that I made.
          Were there plans to do things with these that
          cannot be handled with _WIN32/WIN32 macros or
          were these old ideas that did not get fully
          cleaned up?

          Jim

           
          • Sean Morrison

            Sean Morrison - 2006-05-20

            Old code that hasn't gotten cleaned up yet.  The code should exclusively be using _WIN32 and avoiding even using that one at all costs whenever possible.

            Granted there are plenty of situations where it may be ideal or desired to utilize something in the win32-specific api (e.g. QueryPerformanceCounter()), but in general the package is moving towards feature-based checks, not system checks.

            So even in that case, instead of using _WIN32 the design would be to add a HAVE_QUERYPERFORMANCECOUNTER symbol in the config header and a corresponding check in the configure.ac file (or not, it's not really important if it's win32 only).  That way, the symbol can be autodetected for other (non _WIN32) systems where said feature might actually be available.

            In all, this is a major on-going effort as the package was based around system checks initially (especially bsd vs. sysv) but that turns into a maintenance nightmare as the years progress.  Testing for and/or declaring individual features isolates that feature and makes it easier to automatically accommodate new platforms that emerge.

             
      • Sean Morrison

        Sean Morrison - 2006-05-20

        The raytracer basically sits in a unthrottled idle loop waiting on input (so it can still respond to events, if I recall correctly) causing it to be full-cpu.  This only happens on Windows at the moment due to how the event management was set up in the display manager.  It should of course be using something more akin to a select() on a socket or at least sleeping to keep things sane.

        Cheers!
        Sean

         

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks