> Hmm, I've never looked into this problem either. I have used VC projects > when I worked on windows, but now I am trying to port my Linux > things on NT. > The size of this package is of the ROOT order and includes libs and number > of bin files, etc. It is not convinient to convert it into VC projects. On > the other hand I can not push my users or people willing to download the > source and recompile it on windows to install and fight with cygwin. You may have to choose whichever you consider to be the lesser of two evils. What I have done is to deal with Cygwin for building Root myself and make Visual Studio projects for the packages I have written which will spare others the need. But I've done this starting from scratch rather than converting an existing system, which spreads the pain out a bit. You might also want to consider moving from a Unix-like model of software distribution, which emphasizes everyone rebuilding from the sources, to a more Windows-like model where the binaries are distributed. True, anyone creating their own applications would need to face the build problem, but if you provide a binary distribution of the DLLs, it may become a much smaller problem assuming the user code is a small fraction of the total including all your libraries. In that case you could provide a template VStudio project into which users plug their own source files to link with the libraries you provide. One advantage of the windows platform is that binaries which run on one Windows machine are guaranteed to run on all of them. There is in principle no reason why people who are merely using (as opposed to developing) your packages need to be able to rebuild them on Windows. The perceived problems with this model in the Unix/Linux community are well-known, but in cases where it helps you maintain your products more easily and helps users install them more easily, I think it is silly not to take advantage of it. This is just my approach to the problem - without knowing the details of what you are doing of course it is hard to know whether it is the best solution in your situation. Installing and using Cygwin is not such an imposition either. The installation is relatively painless, and afterward you can just type "make" into a Cygwin window. If your users are also trying to use GEANT4 or CLHEP on Windows, they need Cygwin anyway. > So, what is the problem with nmake Makefile and why it can not be naturally > included in ROOT multiplatform install (Makefile.in i suppose)? I can't tell you for sure; the only way to figure it out would be to go through line by line and see which statements it fails on. You seem to have already discovered one - you cannot assign a symbol with a null value in NMAKE. I imagine the eternal problem of the / vs. \ as path separator will rear its ugly head. Some of the Root meta-configuration files also use "sed" commands, I think, and you don't have that on Windows without Cygwin. Although NMAKE and GNU Make are quite similar, I think they are different in a lot of small ways. I suspect it is going to be more trouble to try to massage the Root-provided Makefiles than to solve the problem in some other way. Dave dcasper@uci.edu
This archive was generated by hypermail 2b29 : Tue Jan 01 2002 - 17:50:34 MET