Objections changing "UserFuncs.h" to <UserFuncs.h>

This is a question for the people working with the DLL Maker. In our office what we do is that under the libraries directories there is 1 DLL Maker directory. Every project uses that DLLMain and all the files in that project. The reason is maintainability, everybody uses the same DLL Maker project and when the project changes there is only 1 to update and all other projects are updates as well.

There is one problem with this approach and that is the userfuncs.h file. That file varies over the projects so you have to have multiple.

With the current implementation FlexsimFuncs.h calls the userfuncs.h with quotes "userfuncs.h" which means that flexsimfuncs starts looking in the same directory as Flexsimfuncs.h and always finds the empty userfuncs that comes with the DLL Maker project. I would like to change that into <UserFuncs.h>. With those angle brackets the compiler starts looking accoording the directories you enter in the INCLUDE environment variable and you can use a UserFuncs.h file in your own directory.

Are there any objections against this change? (and please specify because a simple YES doesn't count)

Hi,

My answer is No and the reason is that someone can have different userfuncs.h for different DLL they develop.
You are using the same and for you it is better to use <>.

I would say wait to do the change and think over how you develop your DLL. What I mean with this is that you maybe can find a solution where you do not need to have <> but still be able to use one userfuncs.h for all your projects.

For my self, it does not for me because I do not use userfuncs.h and I am the only developer of DLL.

Lars-Olof

Hi Lars-Olof,

I'm sorry but I don't completely understand your answer. Are you in favor of the change or against it?

(I'm sorry to make the question so unclear, I've changed the no into yes)

Considering your remark about: "maybe you could use one userfuncs for all your projects", that in itself is nice but doesn't solve the problem you have to change the DLL Maker directory. So next time you update, the userfunctions that you put in there could have been overwritten. And if you do a checkout of the DLL Maker you have to put your own userfuncs back in there.

Hi Steven,

When I first read your question I missed read it, after I have read it again I can say it is better to change it to <> instead of "".

If I understand you right you use one DLL Maker directory for all projects. Is that directory the same as you have connected to Google Source? If yes, I would suggest not to use that approach.

Lars-Olof

Hi Lars-Olof,

Thank you for agreeing

And you are right we use one DLL Maker Directory for all our projects and that directory is exactly the same as the repository version in google source. So why shouldn't we link to the google source project? The idea is that everybody in my team simply checks out the DLL Maker Project and is up and running.

Steven

Hi,

The reason nit to use the same directory is from point of view a safety issue.

First, there is a chance that a change to the code in Google has a bug or is in a experiment state that can break the DLL maker in the version of VS C++ you are using. So if you do a update from Google then you may not be able to compile.

The second reason is that there is a probability that someone (for exampel at your place) do a change in the DLL Maker code and then update Google with that code. And that change should not be updated to Google.

The way should I work with DLL Maker is that I have one directory that handle the update with Google code and then having one directory with the latest tested DLL maker that all my project will use. With this way I can be sure that all my project will compile and work until I have tested the latest code from Google, when the code is tested I update my production directory.

Remember there is no wrong or right way to work, but it is important to know what the pros and cons are for the way that is used.

Lars-Olof

Hi Lars-Olof,

Thanks for the clear explanation. I agree with you about the remarks about that a new version can break a project so that is a valid point.

For the update problem, nobody but me checks it out over the https, so nobody else can make any commits to the repository. But you are right, it is a point of attention.

Steven