I'm currently trying to do a Haskell project using the Test Driven Development methodology. In Java, we can create a nicely structured project containing src and bin folders, then there are main and test folders for unit testing with JUnit. I was just wondering is there a standard way to get such a structure in Haskell? A folder for source a folder for binary, and in the source folder two folders one for testing one for main source.
My reference is alway Structure of a Haskell project and How to write a Haskell program which spell out some defaults which the community more or less seems to follow. It has worked well for me so far but my projects have not been very large as of yet.
What is suggested in Structure of a Haskell project sounds similar to what you have outlined in your post with a few minor modifications like the testing folder is in the same directory as the src folder.
Edit:
cabal init will generate a minimal amount for you including the cabal file with relevant dependencies if you have a any files with imports at least. It is a great start but only part of what you are looking for.
Ideally as a project grows the cabal file and directory hierarchy would be automatically kept up to date, I am unaware of any tool made public that will do this though. It is on my maybe one day list as I am sure it s for many others.
-odir and -hidir can be used with ghc to put the *.o and *.hi files in separate directories. You can read more in GHC user guide's section on separate compilation)
Edit2:
Other relevant/overlapping posts:
Basic Structure of a Haskell Program
Haskell module naming conventions
Large-scale design in Haskell?
The modern answer to this is to use The Haskell Tool Stack. This will structure the project for you using sane defaults.
Related
For a large Fortran project I would like to know what is the accepted way to setup a directory structure. For example I have the main source code (main.f90), some modules (mod_1.f90, mod_2.f90, etc...), and some source code for particular subroutines (subr_1.f90, subr_2.f90, etc...)
I currently have a directory with a mod directory which contains all the mod_*.f90 files and a src directory which contains main.f90 along with the subroutines. Is this the way to do it?
Generally, the best way to learn is to just look at directory structures that other people use. For example, this is geared towards using cmake, but has a fairly typical directory structure:
https://github.com/SethMMorton/cmake_fortran_template
Here's another large project that uses fortran, but their directory structure is a bit different (but still consistent):
https://github.com/cp2k/cp2k
Generally, you do directory structures similar to how you would any other project in another language. You want your folder names to make sense: as an example, you might decide that binaries go in the /bin folder, documentation goes in /doc, examples go in /example, source in /src, a nice readme.txt or readme.md in the root folder, etc.
Really, the most important thing is to just be consistent about it. Don't just toss everything into the root folder unless it's a tiny project with only a couple files.
I've been studying C++ for a while, but this is the first time I'm into a C++ project (a pet configuration parser library). I'm using the Google C++ Testing Framework to test this. But I don't know if I'm doing it right.
Currently, I've ripped off some parts of this Google test library and put it into my projects Test/googletest directory. It works OK, but I wonder if this is how I'm supposed to do this. I'm including the source code of the testing framework in my project and it will be released with my code. This makes me feel uncomfortable.
I wandered through some C++ projects on GitHub, trying to see how other people deal with this. Some have custom framework-lets, and most solve the whole problem with not testing the code at all.
I wonder if I'm taking this right, or otherwise how can I adopt a testing method that will both keep the framework out of my source tree and let me release my code with tests buildable and executable by the user?
Concerning your build, you're doing it right. The gtest readme explicitly states that building gtest (you can pack a libgtest.a from the two object files) along with your project is the prefered way to do it.
Concerning the distribution:
Ideally, you could have your build tool (make, CMake, etc) check out / fetch the required gtest version from its own repository. But I don't think there is much harm if you add an "external" folder to your project and include stuff like gtest in your own repository.
I'm new to scons and trying to port over an existing visual studio solution (.sln) which internally references many VS project files (.vcxproj). The are multiple outputs, including a variety of libraries, and different executables.
From a conceptual point of view I'm unsure if I'm going down the right path and would appreciate any advice on how to do it better.
Here is my setup:
I have a top level SConstruct file at the root of the code depot. Additionally I have one SConscript file for each of my old VS project files. The SConstruct file calls the SConscript function once for each of these SConscript files, in which it specifies the source directory and where the outputs should go as parameters.
Additionally the SConstruct file creates and passes to each SConstruct file an array of scons environment instances. For example, there is one for compiling libraries, one for compiling executables, one for debug config, one for release, etc. and each SConscript file then chooses the one it wants, based on what it's trying to accomplish.
There are a couple things which I was wondering about:
1) Is there a better approach than creating multiple different environments, one for each configuration variation? Is that the expected usage pattern?
2) In visual studio, I could right click on a specific project and select build to only build that project and the projects it depends on, ignoring the rest of the dependency graph in the sln. With scons, is it true that it'll recompute the entire dependency graph every time I trigger a build of a specific library, even though in theory it would only need to compute a little portion of the entire dependency graph.
Thanks for any advice.
Mark
Your approach to having a SConstruct call several subsidiary SConscript files is indeed a good way to organize your projects, and is called a Hierarchical SCons build.
Regarding your questions, here are some things to consider:
Several different environments: Unless you have different compilers or compiler flags per builder or target (library, executable, etc) I would say that the approach you are using is a bit overkill. You could most likely achieve the same with just one environment. If you do need additional flags per sub-directory/builder, then you could consider passing the "main" environment to the subdirs, and in the respective SConscript's, clone the env and add/append what you need as mentioned here. This way the entire solution will be more modular by avoiding repetition and keeping everything common in one central place.
Building certain projects/targets: You can do the same with SCons by selecting the target on the command line, like this $ scons yourTarget. You can make the target names more manageable using the env.Alias() function. SCons does indeed analyze everything before building, but depending on the size of the project, it shouldnt be a problem, its still quite fast. If build performance does become an issue, here are some pointers for improving the performance.
Here are a few extra good things to know:
The SCons documentation is not bad WRT to other open-source tools. At the bottom of that doc page, there are several appendices with lots of extra information. The SCons man page is quite complete too.
Paths can be confusing in SCons if you're not Using the '#' as mentioned here
If you need to deal with MSVS projects, you can use the MSVSProject() and MSVSSolution() builers as mentioned here.
I am new to SVN and I want to commit a code to SVN using TortoiseSVN. I have C++ headers and source of the code, but I don't know how to organize the folders in an efficient way before uploading the version to SVN. Any suggestions about how people usually do? Is there any difference between the structure of codes for different languages, for example C++ or java. Should I follow any specific rules?
Update
So after checking the answers I made things a bit clearer. An usual folder structure is the following for one proyect:
/trunk
/branches
/tags
But I also found a similar structure that I liked a lot, which is:
/trunk #Keep it to developement mode always.
/samples #samples of use
/modules #software modules
/project_modName
/include # .hpp files
/src # .cpp files
/test #unitary tests
/branches #experimental developements (copies of trunk at various stages)
/tags #estable versions
/extras
/3rdparty #libs
/data #necessary data for developement
/doc #documentation
/resources #for window applications
At least I like it for multimedia applications code.
UPDATE 2
This update is just to explain how I am creating my repository. I created a folder called structure_svn. Inside I created the structure showned above. I right click on the parent folder and select import. In URL I write the folder path (file:///c:/svn_repos) so automatically the structure is created under svn_repos, without the folder structure_svn.
I want to remark this beacause the folder you right-click on to import will never appear. I just realized when I tried it, and also is explained on toturials.
The next step is to successfuly divide my code inside the created structure.
Here's how I structure my tree in a programming project (mainly from a C/C++ perspective):
/
src — Source and header files written by myself
ext — External dependencies; contains third-party libraries
libname-1.2.8
include — Headers
lib — Compiled lib files
Donwload.txt — Contains link to download the version used
ide — I store project files in here
vc10 — I arrange project files by IDE
bin — Compiled binaries go here
obj — The compiler's build files
gcc — If your project size justifies it, make a separate folder for each compiler's files
doc — Documentation of any kind
README
INSTALL
COPYING
makefile — Something to automate generation of IDE project files. I prefer CMake.
A few notes:
If I'm writing a library (and I'm using C/C++) I'm going to organize my source files first in two folders called "src/include" and "src/source" and then by module. If it's an application, then I'm going to organize them just by module (headers and sources will go in the same folder).
Files and directories that I listed above in italics I won't add to the code repository.
Edit: Note that I'm using Mercurial, not SVN, so the structure above it tailored for that version control system. Anyway, I see from your update that you already found one that you like.
One huge step forward is making sure all your projects do out-of-source builds, ie put temporary file in $TEMP and put all output file in a dedicated bin/lib directory. If done properly, this leaves you with source directories containing only source. What's in a name.. Apart from 'pure' source files also make sure that everything needed to build the source is in the repository: project files/generators, resources.
Once you got that in place correctly, there's a good chance you only have to put some typical project generated files (like *.suo for Visual Studio) into SVN's ignore list, and you're ready for commit.
Basically you can put in svn just what you want. The only standard you might consider to follow here is the standard repository layout: See here:
Within the project you are right that there exists several best practices. And they are different for each language. E.g a Java Package is organized by namespace. In the C++ world I have seen two main ways how to organize it:
Every Class into a header (.h) and a source file (.cpp) inside the same directory
Header and source is separated (so you have an folder especially for headers) This is usefull for libraries so that this path can be used by upper layer projects.
Then you need a folder for third party libs, another one for the target files and others such as build files or documentation.
You have a good explanation in the next Link if you are noob with svn!!
In other languages I like to put my unit tests in a different directory structure from the production code to keep things cleanly separated. Is there a typical convention in Haskell of how to do that or something similar?
There is a typical convention codified at http://www.haskell.org/haskellwiki/Structure_of_a_Haskell_project.
Additionally, you can add the test build to the main cabal as in https://github.com/ekmett/speculation/blob/master/speculation.cabal
There are some bonuses to the separate cabal method. Namely that testing methods like the quickcheck generators for datatypes are available in a second project-test style cabal that others can import if they are using your data structures in their projects, but I prefer the single cabal approach. It depends on the purpose of your library though.
Haskell testing workflow is useful for more testing info.
I think the best example I've came so far for that is the snap project
http://github.com/snapframework/snap-core
Check the test folder, they develop their own cabal package just for testing, and have a shell script (runTestAndCoverage.sh) that executes the final compiled test suite.
Good Luck.
It's early days for me at Haskell development as well, but I've used cabal to organize my tests under a tests/ subdirectory