bug message reminder

When adressing a model crash or bug, please remember to include an entire model setup in your post that reproduces the crash or exposes the bug. Also add the XBlog.txt file. This is necessary information for people that are trying to help you. Including your model setup can be achieved by adding the zipped run directory (excluding output) as an attachment to the post.

Forum

Source re-structuring

Bas Hoonhout, modified 7 Years ago.

Source re-structuring

Infra-gravity Posts: 362 Join Date: 5/20/11 Recent Posts
Hi all,

Yesterday we restructured the XBeach trunk. We decided to follow a more generic structuring of source code files and include a unit testing framework (which is still in development). The trunk directory now has the following structure:

  • config: linux related build files
  • dist: target directory for compiler, including licence and doc files
  • doc: documentation files, which include doxygen source code documentation (still in development), manuals, reports, etc.
  • lib: third party library files
  • m4
  • src: source codes of makeincludes executable, xbeach library (static and dynamic) and the xbeach executable
  • test: unit testing framework and test code files


Further restructuring and renaming of modules and files will take place in the near future!

Regards,
Bas
Pieter van Geer, modified 7 Years ago.

RE: Source re-structuring

Swell Posts: 176 Join Date: 1/5/11 Recent Posts
While restructuring the source, also the VS2008 and VS2010 solution project files (vfproj) got merged. Both the VS2008 and VS2010 solution files are now located on the highest level of the trunk. Related to the visual studio solutions, the following should be noted:

  • The two solution files (*.sln) now work with the same vfproj files. This means that each change of a project file (add a new F90 file or change include dirs for example) will now automatically result in a changed in both VS solutions.
  • The solution now contains 4 projects in the src directory:
    • makeincludes (creates the include files)
    • xbeachlibrary (this project contains the actual source code of xbeach and exposes all the code in a lib file. Post built it runs makeincludes and copies all gen files to the right place)
    • xbeach (this project only contains the main time loop and produces the exe)
    • xbeachlibrary_dynamic (this project creates a dynamic link library (dll) of the source code in xbeachlibrary).
    when compiling the xbeach project, visual studio will automatically compile makeincludes and the xbeachlibrary first.
  • The solution also contains a test directory. This dir contains two projects:
    • ftnunit (this is an opensource test framework for which we added a project file to be able to compile it with the right settings)
    • xbeachlibrary_test (this is a test project in which the programmer can define tests of individual functions or subroutines. In the near future we hope to run the tests automatically after each commit. For now the tests are executed as a post build action of the project. It will result in a html page summarizing the test results)
  • There is one important difference in how VS2008 and VS2010 treat links between projects. In visual studio it is possible to specify dependencies between projects. For example the xbeachlibrary project is dependent on makeincludes. Both versions of visual studio will first compile makeincludes and after that xbeachlibrary when setting this dependency. VS2010 will automatically add the build directory of makeincludes to the include directories of the xbeachlibrary project (we do not have to specify that). However, VS2008 will not, so to get dependencies working in both VS2008 and VS2010 it is necessary to manually specify the outputdirectory of a linked project in the projects "directories to include".
  • Although the content of the two solutions files is ( and should be) identical, VS2010 defines it as version 11, where the version of the VS2008 file is 10. This is the main reason for having two solution files. Any change of one solution file can generally be copied to the other in order to include the change in a different version of Visual studio. This is only the case when adding projects or folders to the solution, or changing build configurations (in the configuration manager, not changes in the project files).
Pieter van Geer, modified 7 Years ago.

RE: Source re-structuring

Swell Posts: 176 Join Date: 1/5/11 Recent Posts
While updating to revision 2627, most source files will be moved to their new location. Two problems (can) occur:

Problem:
In some cases svn will not delete old directories (and sometimes also not files).
Solution:
The only way to get rid of these files is by deleting them manually (make sure you delete the files marked with a questionmark, when using TortoiseSVN, in all subdirs of the checkout). If you do not know which files to delete, it is also possible to delete one or more directories entirely and update the dir one level higher. Svn will only put back the files belonging to the most recent revision.

Problem:
In case you have local changes svn can give a "tree conflict" error while updating. This is due to the fact that it wants to apply a change and move operation to one file and it does not know how.
Solution:
To solve this problem the best solution is to manually copy the changed files to a temp dir and revert the checkout, update to the most recent version and manually apply the changes to the new layout. Make sure to correctly apply changes to the project files (don't just copy the old ones over the new project files. It will break functionality!!!).