trying to build documentation for a project.
the project uses the doxygen product which rpm contains the /usr/bin/docsetutil binary? Doxygen 1.8.4 generated output Makefile is looking for it...
thx.
That binary is part of the OS X / macOS developer toolchain. On my OS X 10.9.5 system, it exists at /Applications/Xcode.app/Contents/Developer/usr/bin/docsetutil.
I don't know of a workaround for other platforms, so you'll probably want to have a Makefile or a separate Doxyfile or something that just doesn't attempt to build the docset unless you're on an OS X system. And just build the docsets on a Mac, if you have access to one.
It will be interesting to see if a Free replacement docsetutil for GNU/Linux ever pops up, now that the Dash developer has opened the door for offline documentation browsers on other platforms to use his docsets (e.g., Zeal). As far as I know (and I don't know much), the Dash web site at kapeli.com is acting as the central repository at the moment.
ref: I had the same question, and discovered the answer in this otherwise unrelated bug report for the TYPO3 CMS. I'm leaving this answer here for other folks who find this by way of a search engine.
I extensively use Cygwin on a Windows 8 environment (I do not want to go ahead and boot/load Linux directly on the machine). I use the OCamlIDE plug-in for Eclipse and have experienced relatively no problems using this workflow setup.
However, I would like to use Batteries so that I may make use of use of its dynamic arrays among a few other interesting features that will speed up my development process.
I have tried this method: http://ocaml.org/install.html, but I get the following error:
$ sh ./opam_installer.sh /usr/local/bin
No file yet for i686:CYGWIN_NT-6.2-WOW64
What am I missing and how would I configure Cygwin so that it can accept the Opam installer? When I tried yet a different way of building Opam, I got:
'i686-w64-mingw32-gcc' is not recognized as an internal or external command,
as a Makefile error and reason for building failure. It seems something is wrong related to mingw32-gcc, what do I need to install and/or configure for my Cygwin to get it to compile/build things properly. I have wget and curl installed as well.
My overall question: What is the best way to get Batteries installed on my system with the minimum of time spent tracing all of its dependencies by hand? Is there a way I can just build the library module, such as BatDynArray and the includes:
include BatEnum.Enumerable
include BatInterfaces.Mappable
That way I can just call them directly in my code with open...;; and/or include...;;;
OCaml works beautifully on Windows with WODI, which is a Cygwin-based distribution that includes Batteries and tons of other useful packages (which are a pain to install manually on Windows).
I urge you to take a shot at WODI, which I believe to be an indispensable tool for the
rest of us, the forgotten souls, who have to deal with Windows.
First of all, include does not do what you think it does. open Batteries should be exactly what you're looking for. OPAM is not yet solid on windows (maybe Thomas could give an update on where things stand).
Frankly, I would recommend to install a linux on a VM, you should be able to get started with OPAM instantly then. Otherwise, take a look at this package manager for OCaml which focuses on cross platform support: http://yypkg.forge.ocamlcore.org/. I've never tried it myself however. The last package manger you could try is GODI, I'm not sure about its windows support though.
Finally, if none of these options work then it should be possible to install batteries from the source. All you need is OCaml and make. And if there are problems with this approach then you should definitely follow up on them either here or on the bug tracker because batteries does intend to support windows AFAIK.
I installed the OpenNI+NITE+kinect on ubuntu 12.10 today and the samples are working fine. (Ran NITE samples and they work like charm)
I want to start developing in Linux and I like to work with IDE. For ubuntu I have always used Geany or Codeblocks and i was wondering if there was a way to integrate OpenNI,NITE libraries to the IDE's so that I can write, execute, debug the code easily from the IDE itself.
I tried to add the libraries myself in geany but all my attempts failed. :/
Also, when I do make for Sample examples in OpenNI, I get *.d and *.o files but I dont seem to get the executable *.out . So i am not sure how to run the programs.
I am a novice programmer, just starting to learn, So please excuse the noobness in
questions.
Appreciate the Help.
Thanks
Generally if you're doing something non-trivial with Geany you will need to provide your own build system (even simple GNU Make files will do). Geany is intentionally build system agnostic and allows you to run arbitrary build commands which are described in the manual as well as in a helpful article on the wiki.
If you describe in more detail the errors/problems you referred to as "attempts failed" it will likely be possible to provide more concrete solutions.
I have been looking for pros & cons of Autotools and CMake. But I would like to know opinions from people having used one (or both) of these tools for projects.
I used Autotools very basically a year ago and I know that one of the good points is that it relies on shell scripting, thus it does not need to be installed to be run and uses portable shell scripting. But it looks like it is too unix oriented, and it would not be possible to run the configure file on Windows.
I have now to choose a build system tool for an open source project that will have to be compiled for at least Linux & Windows. It is written in C++, and uses a Qt GUI front-end, the rest of it is "generic".
Thanks for you help.
Updated 16th of January 2019: Refined advice as tools evolve.
I have used autotools before for a considerable amount of time.
Currently I make intensive use of meson and cmake only when I need it.
Some personal advice:
for big teams, stick to CMake if you want to make use of the generators for XCode. If you do not need it, I would use Meson directly. Meson, as of version 0.49, also supports finding CMake configuration files (though I did not test yet how well this works). Also, Visual Studio seems to be sufficiently well-supported at this point in time, though, again, I did not try myself. The advantage of CMake is that it has Visual Studio integration.
Drop autotools. Meson covers well everything already. Their cross-compilation model is amazingly understandable. In CMake, last time I checked, everything was quite more difficult.
I have also tried scons, waf, and tup.
The most full-featured, cross-platform system, is CMake, but the DSL from meson will be easier to use for people used to python and others. Meson is starting to support VS also (a VS2015 generator) and some projects already have experimental support for it, for example gstreamer. Gstreamer is compiled in windows as well with meson. Right now there is VS2015 generator and VS2017 but I did not try myself the generators lately. As of meson 0.37.1 needed some work, but they are improving them and current version is already 0.40.
Meson
Pros:
The DSL does not get in the way at all. In fact, it is very nice and familiar, based in python.
Well-thought cross compilation support.
The objects are all strongly typed: you cannot make string substitution mistakes easily, since objects are entities such as 'depencency', 'include directory', etc.
It is very obviuos how to add a module for one of your tools.
Cross-compilation seems more straightforward to use.
Really well-thought. The designer and main writer of Meson knows what
he talks about very well when designing a build system.
Very, very fast, especially in incremental builds.
The documentation is 10 times better that what you can find in cmake. Go visit http://mesonbuild.com and you will find tutorial, howtos and a good reference. It is not perfect but it is really discoverable.
Cons:
Not as mature as CMake, though, I consider it already fully usable for C++.
Not so many modules available, though, gnome, qt and the common ones are already there.
Project generators: seems VS generator is not working that well as of now. CMake project generators are far more mature.
Has a python3 + ninja dependency.
Cmake
Pros:
Generates projects for many different IDEs. This is a very nice feature for teams.
Plays well with windows tools, unlike autotools.
Mature, almost de-facto standard.
Microsoft is working on CMake integration for Visual Studio.
Cons:
It does not follow any well known standard or guidelines.
No uninstall target.
The DSL is weird, when you start to do comparisons and such, and the strings vs list thing or escape chars, you will make many mistakes, I am pretty sure.
Cross compilation sucks.
Autotools
Pros:
Most powerful system for cross-compilation, IMHO.
The generated scripts don't need anything else than make, a shell and, if you need it to build, a compiler.
The command-line is really nice and consistent.
A standard in unix world, lots of docs.
Really powerful command-line: changing directories of installation, uninstall,
renaming binaries...
If you target unix, packaging sources with this tool is really convenient.
Cons:
It won't play well with microsoft tools. A real showstopper.
The learning curve is... well... But actually I can say that CMake was not that easy either.
The use of recursive make is pervasive in legacy projects. Automake supports non-recursive builds, but it's not a very widely used approach.
About the learning curve, there are two very good sources to learn from:
The website here
The book here
The first source will get you up and running faster. The book is a more in-depth discussion.
From Scons, waf and tup, Scons and tup are more like make. Waf is more like CMake and the autotools. I tried waf instead of cmake at first. I think it is overengineered in the sense that it has a full OOP API. The scripts didn't look short at all and it was really confusing for me the working directory stuff and related things. At the end, I found that autotools and CMake are a better choice. My favourite from these 3 build systems is tup.
Tup
Pros
Really correct.
Insanely fast. You should try it to believe it.
The scripting language relies on a very easy idea that can be understood in 10 minutes.
Cons
It does not have a full-featured config framework.
I couldn't find the way to make targets such as doc, since
they generate files I don't know of and they must be listed in the output before being generated, or at least, that's my conclusion for now. This was a really annoying limitation, if it is, since I am not sure.
All in all, the only things I am considering right now for new projects is are Cmake and Meson. When I have a chance I will try tup also, but it lacks the config framework, which means that it makes things more complex when you need all of that stuff. On the other hand, it is really fast.
I would not recommend autotools for Windows. Use CMake.
Why? Windows doesn't have a native sh.exe, and the emulation is slow. It's also very easy to get configury stuff wrong. I'm not saying it's impossible in CMake, but CMake surely abstracts more away, so you worry about less. CMake documentation can be a bit hard to read, but once it's set up, you should be fine for all toolchains ever supported by CMake. CMake also integrates testing, packaging etc...
Autotools is slow on Windows, does not work easily with MSVC, and has weird quirks with Windows (and other OSes) that are hard to debug, and hard to fix. libtool also sucks on Windows, where it often refuses to build a shared library even, if you think it should and could. Toolchain relocation issues are also prevalent with libtool, which may look at the wrong files in a user's toolchain. CMake is a lot easier in this regard. It assumes normal things about the target platform and creates generic and good build instructions.
Also, CMake has coloured output :) and nice progress percentages.
PS: I just have some experience with CMake and autotools on Windows as a user. CMake tends to work, autotools tends to bite your ear off when you're not looking, and smile at you when it fails due to some strange error...
I downloaded GNUStep and installed it, however I am not sure where I can find an IDE. does anyone know what programs serve as a GNUStep IDE/where to get them? Failing that, does anyone know of a tutorial on how to create and compile a basic GNUStep program?
Well my experiences with that are devastating. ProjectCenter the IDE distributed for GNUstep does not work here at all the debugger intergration is well not existant. But that's what you get with GNUstep. There is Gorm as interface builder and ProjectCenter. Not more. That's very discouraging. The best you can do with Objective-C is currently having a Mac in some form and use XCode. That's the best you can get currently, and I expect that won't change in any forseeable future.
Now you should step back and just use the "plain" old Makefile route. There is a somewhat very rough tutorial about GNUStep makefile starting somewhere below
http://wiki.gnustep.org/index.php/User_Guides
Regards
Friedrich
As Friedrich already mentions in his post above there is Gorm for creating interfaces and ProjectCenter as IDE (gdb integration is worked on as far as I know).
For compiling GNUstep programs you are best of using GNUstep-make. You can find some recently updated tutorials here:
Basic GNUstep-make tutorial
More advanced GNUstep-make tutorial
And there is always the whole bunch of newsgroups, irc and mailinglists where you can usually get quick answers to your questions. Maybe not on IRC currently.
You can try to make eclipse
work with gnustep/msys/mingw:
http://wirecode.blogspot.com/2007/11/objective-c-and-eclipse.html
http://djsilenceboy.wordpress.com/2012/02/13/install-minggw-and-gnustep-for-ccobj-c-for-windows/