Dick Hollenbeck wrote: > CMake does not solve this problem. But I think it is an easier build > system overall than automake/autotools.
For 1.0 I propose to not change the buildsystem/buildtooling and find a solution based on Duane's ideas. What we do after 1.0 is an other topic, then. Best regards Dirk > 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 > _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
