While not explicitly documented, Visual Studio allows commas to be used to 
delimit Additional Directories. Many of our projects are set up this way. An 
error is generated by MakeItSo when commas are used.

To fix please replace the following line in ProjectParser_CPP.cs for both 2008 
and 2010:

    List<string> additionalLibraryDirectories = Utils.split(strAdditionalLibraryDirectories, ';');

with this line:

    List<string> additionalLibraryDirectories = Utils.split(strAdditionalLibraryDirectories, ';', ',');

Even if a project is a static library, you may want to build a .so in the Linux 
version instead of a .a

We could add an option to do this.

The config should allow you to specify that a project should not be converted. 
For example, you may have a project that is Windows-specific and you do not 
want to convert it in a Linux build

-

I don't know if Makefiles allow this but it could be worth checking.

____ What steps will reproduce the problem?
1. Generate your makefiles through Make-it-So
2. Build your app on Linux
3. Change something in a project which depends on an already generated 
library/exe project, and launch make again. 

____ What is the expected output?
When building a project, I don't expect Make to actually rebuild every library 
(previously generated by Make-it-So) my project depends on.

In my case: I have an app which depends on 1 exe and 2 libraries, which 
themselves depend on 5 other libraries, and so on. And everytime I do a make on 
my app, the "ar rcs" part is called which can be long with large libraries.

Someone should check if there's some way to indicate in the Makefile not to 
execute this part if nothing has changed since the last build.

When compiling a dll/shared object project that references a static library, 
the current command line settings cause link errors due to there being no -fPIC 
option set for static library projects.

make-it-so ignores PropertySheets.

I tried to add code to check PropertySheets to make-it-so.
I think it is easy, because there is code to get PropertySheets in 
SolutionParser_VS2008/ProjectParser_CPP.cs.

I attach patch file for SolutionParser_VS2010/ProjectParser_CPP.cs.
If there is no problem, could you add code to check PropertySheets.

Best Regards

When generating your application, make will basically follow each step in the 
Makefile and execute them.
However even when all files are up to date, il will invoke the "ar rcs" step in 
the generation which is a huge waste of time for large projects. 

To improve this, here's what I successfully tried by manually changing noe of 
my project's makefile:

_____ CHANGE THIS _____

.PHONY: Debug Release
Debug: create_folders [List of .o files]
ar rcs [path to generated lib/exe] [list of .o files]

[same for Release]

_____ TO THIS _____
.PHONY: Debug Release
Debug: create_folders [path to generated lib/exe]

[path to generated lib/exe]: [List of .o files]
ar rcs [path to generated lib/exe] [list of .o files]


----------------------

This allow make not to generate everything if there's no change in the project.

As title.

Write HowToReportProblems wiki page

If the command-line is unrecognized (i.e, including --help, /? etc) we should 
display the basic help.

This can should the command-line options, and also the url of the wiki.

I am getting the following error message when running the makeitso while 
parsing my solution file.

"
Fatal error: Failed to parse solution trading-platform_vs2008.sln ['call' 
failed to call function after 20 tries.]."

I have attached the error logs as well as solution file for your reference.
I am using VS 2008 to compile C++ programs.

Please do provide the fixed code as soon as possible.

When generating the makefile, the "Library_Path" and "Libraries" sections are 
generated correctly, but these are not used in the output command line options 
for CPP_DLL projects (as they are in CPP_EXECUTABLE projects).

This causes any static library references to be undefined in the resulting 
shared object file.

What steps will reproduce the problem?
1. Create a C++ project with source files not using ".cpp" or ".c".
2. ???
3. Profit

What is the expected output? What do you see instead?
The expected output is "proper" makefiles. The actual output is "improper" 
makefiles.

What version of the product are you using? On what operating system?
Visual Studio 2008, Windows XP 

Please provide any additional information below.
The parsing for C++ projects checks if the file extensions match:
.c
.cpp

Unfortunately, common C++ source file extensions include (according to "man 
g++"):
.cc
.cp
.cxx
.cpp
.CPP
.c++
.C

I modified the code to include the following extensions:
.cxx
.cc
Note I made the changes mostly as a quick fix for my own purposes -- A more 
complete fix might include the common extensions and allow additional 
extensions from the config file?

All our projects have 32 and 64 bit builds, these equate to Win32 and x64 
platform types. For both platform types the configuration names are the same 
(Release and Debug).

When I convert the projects all the makefiles end up with two Debug and two 
Release target configurations with nothing to identify them uniquely.

To fix please replace the following line in ProjectParser_CPP.cs for both 2008 
and 2010:

           configurationInfo.Name = Utils.call(() => (vcConfiguration.ConfigurationName));

With this code:
            // Get target name (e.g. Release|Win32)
            string pipeString = Utils.call(() => (vcConfiguration.Name));
            // Replace '|' with '_'
            var pipe_index = pipeString.IndexOf("|");
            configurationInfo.Name = pipeString.Substring(0, pipe_index);
            configurationInfo.Name += "_";
            configurationInfo.Name += pipeString.Substring(pipe_index + 1);

This will generate makefiles with target names Release_Win32, Release_x64, 
Debug_Win32 and Debug_x64.

Since this will break exiting usage you might want to make it a command line 
option to use this new convention.

What steps will reproduce the problem?

MakeitSo Version 1.2.0

1. run makeitso -file=RhmDxfDwgCheckCsv.sln    (Attachment)

2.
It may be, the problem is with placeholders for system variables that are 
defined in a CMD file:

set GILIB = M: \
set VSRHMENV = D: \ SANDBOX \ RHMTRUNK
...

rem RhmCore  
set RHMCOREH =% VSRHMENV% \ RhmCore
set RHMBASEH =% VSRHMENV% \ RhmGenBase
set RHMERRH =% VSRHMENV% \ RhmErrCodes
set RHMRXH =% VSRHMENV% \ RhmRegex

set PATH =% PATH%; ...; ...

rem use vstudio
"C: \ Program Files \ Common Files \ Microsoft Shared \ MSENV \ VSLauncher.exe" 
"RhmDxfDwgCheckCsv.sln"
rem or MSBUILD

C: \ WINDOWS \ Microsoft.NET \ Framework \ v4.0.30319 \ msbuild [pathto] \ 
RhmDxfDwgCheckCsv.vcxproj / p: configuration = debug / t: rebuild
[...]

The aim then is the automatic code generation via makeitso and gcc also for 
linux...

3. What is the expected output? What do you see instead?

Parsing rhmdxfdwgcheckcsv.sln
- parsing project RhmDxfDwgCheckCsv
  - FAILED (Ung�ltiger URI: Das URI-Format konnte nicht bestimmt werden.)
- parsing project RhmDxfDwgCheckCsv_Test
  - FAILED (Ung�ltiger URI: Das URI-Format konnte nicht bestimmt werden.)
Parsing succeeded.
Creating makefile...
Creating makefile succeeded.

What version of the product are you using? On what operating system?

MakeitSo Version 1.2.0, WinXPProf

I have tried to meeting closer to the problem of using the debug Repsitory 
(VS2008 and VS2010), but the version from the repository behaves differently:

[SolutionParser.cs - VS2010]

 case ProjectType.CPP_PROJECT:
 {
  //...
   VCProject vcProject = Utils.call(() => (project.Object as VCProject));
  //Error:  vcProject is NULL!!!
 ...
 }

Please provide any additional information below.

I would like to participate to help solve the path-token-problem within the 
vcxproj. The realization of makeitso.config is too static and hardly applicable 
here.

Thank you for this exellent work and your efforts..


Bernd

Allow the tests to run in parallel:
- Make the TestRunner launch multiple MakeItSo and cygwin windows.
- Run make with the -j option

Write converting solutions for Cygwin wiki page. Link from main page?

What steps will reproduce the problem?
1. Create a random VC project which contains at least one source file which is 
marked as "excluded from build" (this can be set to any sourcefile per 
configuration in "configuration properties/common" of the files' properties.)
2. let makeItSo create the makefile
3. search the generated makefiles for the source which shouldn't be compiled

What is the expected output? What do you see instead?
Instead of not seeing a compilation directive for the source file in the 
generated makefile, the flag "exclude from build" (per build configuration) 
seems to be ignored and compilation directives are generated.

What version of the product are you using? On what operating system?
MakeItSo_1.2.2

Please provide any additional information below.

gcc's linker is (annoyingly) fussy about the order that static libraries are 
given to it if there are dependencies between them.

We need to fix this.

i wanna  make this project better .make it visual operation.

What steps will reproduce the problem?
1. Parse solution,  converted from vs 2012 by simply replacing "12.00" by 
"11.00" in first line(see attachment)

What is the expected output? What do you see instead?

I expect that all projects in solution will be parsed, but that one wasn't. 
Can't understand, why. Output from Makeitso was redirected to log(see 
attachment), but there are no error messages about skipping due to an error, or 
something like that.

What version of the product are you using? On what operating system?
1.2.0, because 1.2.1 crashes on startup. Windows 7, x86_64

Please provide any additional information below.

Executables and libraries in C as well as C++.

What steps will reproduce the problem?
1.when I run makeitso.exe produce

Index was outside the bounds of the array. 
Parsing .\finalUUID.sln
Fatal error: Failed to parse solution .\finalUUID.sln [Visual Studio 2010 cannot
 be loaded].

What is the expected output? What do you see instead?

 Need makefile
What version of the product are you using? On what operating system?
1.2.2 , Visual Studio (32 bit platform), Windows 7 64bit os

Please provide any additional information below.

since the project is not maintained, just a tip. If you want to support any 
inherited values (from property sheets, for example) just replace the use of 
VCConfig.Evaluate with IVCRulePropertyStorage.GetEvaluatedPropertyValue

like:IVCRulePropertyStorage rule = 
(IVCRulePropertyStorage)vcConfiguration.Rules.Item("CL");
string strAdditionalIncludeDirectories = 
rule.GetEvaluatedPropertyValue("AdditionalIncludeDirectories");
for getting all additional include directories

sln2mak does something with them??
254              m_MakFWriter.WriteLine("%.res: %.rc");
255              m_MakFWriter.WriteLine("\t$(RC) $(CPPFLAGS) -o $@ -i $<");
256              m_MakFWriter.WriteLine("");

What steps will reproduce the problem?
1. Consider a solution file with a project file and project file inherit from a 
property file [vsprops]
2. The include paths from the property file is not getting inherited into the 
project file
3.
    <Tool
        Name="VCCLCompilerTool"
        Description="Building the project $(ProjectName)"
        AdditionalIncludeDirectories="$(SolutionDir)..\api\OpenMAX\Khronos;
        $(SolutionDir)..\api\OpenMAX\QCOM;
        $(SolutionDir)VFEDriver\VFEDriverWin\inc;
        $(SolutionDir)..\platform\OSAbstraction\inc;
    />

4. The <AdditionalIncludeDirectories> from the property file is not getting 
into the inherited project file.

What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?
Visual Studio 2008, Windows 7

Please provide any additional information below.

I downloaded makeitso from the featured download link and unzipped it in a 
directory on the PATH. When running it (under Win7 64bit) without any 
parameters I'm getting the following output:

>>>
Parsing .\myproject.sln
Fatal error: Could not load file or assembly 'EnvDTE, Version=8.0.0.0, 
Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. 
The system cannot find the file specified.
<<<

Given the purpose of this project, it shouldn't be unusual that I don't have 
VisualStudio installed. I did a web search for the error message above and 
everything I found mentions devenv.exe. Could it be that this is not a Release 
build?

Thanks for your help (and coming up with this project!)!

________ What steps will reproduce the problem?

Let's say you have the following architecture:
MainApp
|-- Source
|   |--- MainSource1.cpp
|   |--- MainSource2.cpp
|   `--- DependancyFile.cpp
|-- Include
|   |--- MainInclude1.h
|   `--- MainInclude2.h
`-- SecondaryApp      <------------------------- Doing a "make" on this one
    |--- SecondaryApp.makefile
    |--- Source
    |    |--- SecondarySource1.cpp
    |    `--- SecondarySource2.cpp
    `--- Include
         |--- SecondaryInclude1.h
         `--- SecondaryInclude2.h

Now imagine you're building your SecondaryApp and you included the 
MainSource1.cpp in your solution because you need it. The MainApp doesn't need 
to be built, hence why there isn't any makefile.

When building SecondaryApp, DependancyFile.d and .o won't be placed in the 
SecondaryApp/gccDebug directory but in the SecondaryApp/source directory.



________ What is the expected output? What do you see instead?

Have the *.d and *.o files placed in the correct directory (as indicated before)



________ How to fix it?

- Change the Debug/Release Configuration (basically just remove the ../)
- Change the file output and input paths when compiling the file

Example based on my work - Change this:
# Builds the Debug configuration...
.PHONY: Debug
Debug: create_folders ./gccDebug/../source/DependancyFile.o 
./gccDebug/source/SecondarySource.o ./gccDebug/source/SecondaryMain.o 
    g++ ./gccDebug/../source/DependancyFile.o ./gccDebug/source/SecondarySource.o ./gccDebug/source/SecondaryMain.o  $(Debug_Library_Path) $(Debug_Libraries) -Wl,-rpath,./ -o ../../serveur/gccruntime/SecondaryApp.exe

# Compiles file ../source/DependancyFile.cpp for the Debug configuration...
-include ./gccDebug/../source/DependancyFile.d
./gccDebug/../source/DependancyFile.o: ../source/DependancyFile.cpp
    $(CPP_COMPILER) $(Debug_Preprocessor_Definitions) $(Debug_Compiler_Flags) -c ../source/DependancyFile.cpp $(Debug_Include_Path) -o ./gccDebug/../source/DependancyFile.o
    $(CPP_COMPILER) $(Debug_Preprocessor_Definitions) $(Debug_Compiler_Flags) -MM ../source/DependancyFile.cpp $(Debug_Include_Path) > ./gccDebug/../source/DependancyFile.d




!! ------------ BY THIS ------------ !!




# Builds the Debug configuration...
.PHONY: Debug
Debug: create_folders ./gccDebug/source/DependancyFile.o 
./gccDebug/source/SecondarySource.o ./gccDebug/source/SecondaryMain.o 
    g++ ./gccDebug/source/DependancyFile.o ./gccDebug/source/SecondarySource.o ./gccDebug/source/SecondaryMain.o  $(Debug_Library_Path) $(Debug_Libraries) -Wl,-rpath,./ -o ../../serveur/gccruntime/SecondaryApp.exe

# Compiles file source/DependancyFile.cpp for the Debug configuration...
-include ./gccDebug/source/DependancyFile.d
./gccDebug/source/DependancyFile.o: ../source/DependancyFile.cpp
    $(CPP_COMPILER) $(Debug_Preprocessor_Definitions) $(Debug_Compiler_Flags) -c ../source/DependancyFile.cpp $(Debug_Include_Path) -o ./gccDebug/source/DependancyFile.o
    $(CPP_COMPILER) $(Debug_Preprocessor_Definitions) $(Debug_Compiler_Flags) -MM ../source/DependancyFile.cpp $(Debug_Include_Path) > ./gccDebug/source/DependancyFile.d

This issue comes when the .sln file is not in the root folder where all 
projects are stored.
For large projects and numerous dependencies its useful to keep dependencies 
outside of the base project folder

What is the expected output?
$(CPP_COMPILER) $(Debug_Preprocessor_Definitions) $(Debug_Compiler_Flags) -c 
../../modules/juce_audio_basics/effects/juce_IIRFilter.cpp 
$(Debug_Include_Path) -o 
gccDebug/modules/juce_audio_basics/effects/juce_IIRFilter.o


What do you see instead?
$(CPP_COMPILER) $(Debug_Preprocessor_Definitions) $(Debug_Compiler_Flags) -c 
../../modules/juce_audio_basics/effects/juce_IIRFilter.cpp 
$(Debug_Include_Path) -o 
gccDebug/../../modules/juce_audio_basics/effects/juce_IIRFilter.o

I took the liberty to implement vs2012 support. 
Now there's support for DirectoriesSetting, that is "VC++ Directories Settings" 
that moved from "Options" to "Project Settings" (that was on vs2010).
I also implemented support for changing the linker/assembler.
And I added support for the configuration alias named 'All', this is to 
simplify the config xml when you need to use same arguments on Build and on 
Release.

What steps will reproduce the problem?
1. Create a random VC project which contains at least one source file with the 
file ending 'C' but which is marked as "compile as C++ code" (this can be set 
to any sourcefile per configuration in "configuration 
properties/c_c++/extended/type of compilation" of the files' properties.)
2. let makeItSo create the makefile
3. search the generated makefiles for the c-source which should be compiled as 
c++ code

What is the expected output? What do you see instead?
Instead of seeing $(C_COMPILER) used to compile these sort of files, i'm 
expecting to see $(CPP_COMPILER) there.

What version of the product are you using? On what operating system?
MakeItSo_1.2.2

Please provide any additional information below.
I assume the opposite (compile file with cpp-ending as c source) being equally 
impossible atm.

MakeISo is not compatile with VisualStudio2012 VCXPROJ

What steps will reproduce the problem?
1. I am using 3 C# project and one C++ project in the solution 
2. MakeItSo successfully parsed all the project but after that it is throwing a 
fatal error.
3. Fatal error: Failed to parse solution dataacq.sln [Unable to cast object of 
type
 'MakeItSoLib.ProjectInfo_CSharp' to type 'MakeItSoLib.ProjectInfo_CPP'.].

What is the expected output? What do you see instead?
Expecting the makefile to be created for the project

What version of the product are you using? On what operating system?
MakeITSo 1.2 and Visual Studio 2010

Please provide any additional information below.

When we implicitly link libraries from projects we depend on, we should try to 
find the configurations with the best match name - using the Levenshtein thing. 
At the moment we only match on exact matches, I think.

What steps will reproduce the problem?
1. I am using Windows 7 and when I do a make, I get the following error.

******
mkdir -p bin/monoDebug
The syntax of the command is incorrect.
******

This is because of the fact that Windows uses \ as a path separator and we have 
/ in the command. I don't think this is a real bug, but is there some kind of a 
workaround for this?

What is the expected output? What do you see instead?

******
mkdir -p bin/monoDebug
The syntax of the command is incorrect.
******

What version of the product are you using? On what operating system?
1.2.0

Please provide any additional information below.
Windows 7 Home Basic

What steps will reproduce the problem?
1. Unload at least one of your projects in solution (Properties -> Unload 
project)
2. Save solution
3. Run make-it-so

What is the expected output? What do you see instead?
Conversion is expected, but whole conversion of solution is aborted due to the 
exception.


What version of the product are you using? On what operating system?
1.2, Windows 7, VS2010


Please provide any additional information below.
I provided a patch, which checks some basic properties of the project and if 
the project appears to be unloaded (unfortunately there's no direct property), 
the current project is simply skipped from conversion and a warning is sent to 
the command line.

What steps will reproduce the problem?

If you have separated Visual Studio's project and source files into different 
folders the object and definition files will not be generated with valid names.

Example) Say source is located "../src/foobar.c"

the generated make file will try to output "gccDebug/../src/foobar.o" which 
does not work.

Quick fix I did for this is by modifying the MakeItSo source in 
MakefileBuilder_Project_CPP.cs (I'm using a C framework) and stripping the 
relative path component from the target files by:

foreach (string filename in m_projectInfo.getFiles())
{
    var fileNameOnly = Path.GetFileName(filename);
    string path = String.Format("{0}/{1}", intermediateFolder, fileNameOnly);
    string objectPath = Path.ChangeExtension(path, ".o");
...

and further down

foreach (string filename in m_projectInfo.getFiles())
{
    // We work out the filename, the object filename and the 
    // dependencies filename...
    var fileNameOnly = Path.GetFileName(filename);
    string path = String.Format("{0}/{1}", intermediateFolder, fileNameOnly);
    string objectPath = Path.ChangeExtension(path, ".o");
    string dependenciesPath = Path.ChangeExtension(path, ".d");
...

Folder names with spaces don't work - at least in the 'clean' step. I'm not 
sure about compiling.

Should check:
- Compiling
- Output folders
- Intermediate folders
- Solution root folder
- Project root folder

Write MakeItSoConfig  wiki page

When converting complex solutions, parsing projects that have been configured 
to be ignored can waste a huge amount of time.

I want to build a makefile using makeitso but it ends up giving me that error

By default Make-it-So will generate targets for both Debug and Release 
configurations. That means both of them are compiled when launching a build and 
results in a huge waste of time when building large projects.

The aim would be to add an option to the config file when you only want one 
target (Debug/Release) to be generated.

For both C++ and C# projects you should be able to specify the compiler version 
in the MakeItSo.config file.

This could be a different version from the default, or you may need to specify 
the compiler if it is not on the path for some reason.