CMake does not solve this problem. But I think it is an easier build system overall than automake/autotools.
We switched to it a year ago for Kicad and have had no regrets. One of the main advantages is that it does not require Cygwin or Mingw. It can run on straight windows. The reason of course is that the shell scripts are replaced with the CMAKE language scripts and all you need for that is the CMAKE executable, which directly calls the tools without shell scripts being in the picture. I think it can be easier for windows folks to build the project. And then all a person needs to do to adjust these settings that you describe here is to edit a text file, or run an interactive UI tool which give a set of fields to edit. I have never liked autotools or automake from a developers point of view. They are not terrible from a users point of view though. In either case, developers point of view or users point of view, I think CMake wins each of those two comparisons. Here is a sample CMakeLists.txt file which is what drives the construction of a Makefile. http://kicad.svn.sourceforge.net/viewvc/kicad/trunk/kicad/CMakeLists.txt?revision=1474&view=markup Notice the "options" statements. These are your configuration variables. You have a CMakeLists.txt file in each of the main source directories, and they are tied together from the top. My $.02 Dick Duane Ellis wrote: > A while ago - w.r.t. rev 1.0 - we where talking about the --with-ftd2xx > option. > > The general idea was to add a "path" option of some sort. > > The question I have is this: What should the option be pointing at? > > Details and commentary follow. > > -Duane. > > ================================================== > > For all systems > There is the question of where is the "H" file? > There is the question of where is the LIB > And is it a STATIC or SHARED library? > > ================================================== > > For cygwin - what would one expect? > > There is *NO* standardized "how to install it" set of instructions > telling the *victim* what to do. maybe there is - but I cannot > find it and do not know where to look. > So we must set our own expectations and tell the user what to do. > > What I do is this: > I unzip the ZIP file - next to openocd. > > Hence, I have (under cygwin) > /home/duane/work/openocd.VERSION/.... > /home/duane/work/ftd2xx.d > > I would like an option that says: > "this is the directory where I unzipped the ZIP file" > > What do you do? > What is expected? > > The problem lies with 'ftdi' they did not state what is "proper" > so everyone does it differently. > > ================================================== > > For MingWin - I don't know. I do not use MingWin. > > Spen? Do you hav a comment? > Do others? > Input would be appreciated. > > ================================================== > > For Linux - it is entirely 50% not 100% a different matter, FTDI set a > standard, they have a readme file. But - that "readme.dat" file is > incomplete. > > Functionally, it tells the *victim* how to install the ".so" file and > setup the > standardized version numbered sym-link in two places. > > (1) /usr/lib > and (2) /usr/local/lib > > The readme file does not speak about "ftdi2xx.h" - so one is left to wonder > where it is put. I suspect - it is in a *RANDOM* place - or not even > installed anywhere. > > What should we do? > > Option #1 - is - we assume the user has followed the instructions and > "installed the . > so file" and nothing else. > > This leaves the need to have a --config-option to point where the > ".h" file > can be found. > > Option #2 - is we assume did not install it - > > Should we expect the "--config-option" to point at the directory > where they > exploaded the tar ball. > > Option #3 - Same as Option #2. > But instead of linking with the ".so" file - we link with the > static lib. > > ================================================== > > From a design point of view I am faced with a dilemma. > > There is no defined way one would expect it the package to be installed :-( > So - what ever we do - we will force something on the user. > > Basically we tell the user Do X/Y/Z - and it will work, do something > else and it will not. > or we end up with configure option-hell. > > ================================================== > > I suggest we do the following: > > Remove: --with-ftd2xx > > Based on "--enable-ftd2xx_libftdi" - we look for the H and LIB files > we look in _the_standard_places_ ie: > /usr/lib, /usr/local/lib, and /usr/include,and /usr/local/include > > And then demand/complain if the following items where not set. > These options will be used to resolve the problems - if needed. > > (1) Add: --with-ftd2xx-libdir=<PATH> > It becomes yet another "-I" paths. > > (2) Add: --with-ftd2xx-incdir=<PATH> > It becomes yet another "-L" and "-rpath" options > (because it might be a 'shared library' in a non-standard place) > > (3) Add: --with-ftd2xx-zipdir=<PATH> > Assumes you did not install it - just unzipped it > Under cygwin, you downloaded the ZIP file > And this is the directory where you unzipped it. > > (4) Add: --with-libftd2xx-tardir=<PATH> > Assumes you did not install it, just unzipped it. > Same as (3) but for Linux/Unix > We would default to the *static* version. > > (5) MingWin - And I am not sure about MingW32 situation. > I believe one of the above might handle the situation. > Can somebody offer a comment ( ? Spen ? ) > > Problems: > Dealing with "i386" vrs "x86_64" subdirectories > I'm looking for an autoconf reference if there is a standard way or > not. > If somebody knows this already - a reference would be helpful. > > ================================================== > > TEST - > > I cannot test all combinations - help will be appreciated. > > ================================================== > > **END** > > -Duane. > > > > _______________________________________________ > Openocd-development mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/openocd-development > > _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
