Having made my configure.ac and Makefile.am files, I see myself having to perform autoreconfs so autoconf will not complain about undefined macros such as AC_INIT_AUTOMAKE. This fills my directory with files like aclocal.m4, Makefile.in, install-sh, confdefs.h, depcomp, autom4te.cache, and a .deps directory.
Having read the documentation I just cannot get what are the minimum number of these files to be shipped with my source code, that are platform independant. Either the documentation is not clear enough, they expect me to read much more or it is me that I don’t have enough time. I am sort of in a rush.
What are these files and what are the tasks that the compiler person, in their system, must perform?
For someone wanting to just compile and install your project the dist target family create tarballs, these files should be enough. For someone wanting to participate to your project I guess you have to distribute all the non generated files because this kind of user should have installed all the development tools needed to generate them
Related
I am learning CMake, and I feel hard to understand when I should use find_package.
For separate compilation, we need to let the compiler knows where to find the header file, and this could be done by target_include_directories. For linking, we need to let the linker knows where the implementation is, and this could be done by target_link_libraries. It seems like that is all we need to do to compile a project. Could anyone explain why and when we should use find_package?
If a package you intend allows for the use of find_package, you should use it. If a package comes with a working configuration script, it'll encourage you to use the library the way it's intended to be used likely come with a simple way to add include directories and dependencies required.
When is it possible to use find_package?
There needs to be either a configuration script (<PackageName>Config.cmake or packagename-config.cmake) that gets installed with the package or find script (Find<PackageName>.cmake). The latter one in some cases even comes with the cmake installation instead of the package installed, see CMake find modules.
Should you create missing scripts yourself?
There are several benefits in creating a package configuration script yourself, even if a package doesn't come with a existing configuration or find script:
The scripts separate the information about libraries from the logic used to create your own target. The use of the 2 commands find_package and target_link_libraries is concise and any logic you may need to collect and apply information like dependencies, include directories, minimal versions of the C++ standard to use, ect. would probably take up much more space in your CMakeLists.txt files thus making it harder to understand.
If makes library used easy to replace. Basically all it takes to go with a different version of the same package would be to modify CMAKE_PREFIX_PATH, CMAKE_MODULE_PATH or package-specific <PackageName>_ROOT variables. If you ever want to try out different versions of the same library, this is incredibly useful.
The logic is reuseable. If you need to use the same functionality in a different project, it takes little effort to reuse the same logic. Even if a library is only used within a single project, but in multiple places, the use of find_package can help keeping the logic for "importing" a lib close to its use (see also the first bullet point).
There can be multiple versions of the same library with automatic selection of applicable ones. Note that this requires the use of a version file, but this file allows you to specify, if a version of the package is suitable for the current project. This allows for the checking the target architecture, ect. This is helpful when cross compiling or when providing both 32 and 64 bit versions of a library on Windows: If a version file indicates a mismatch the search for a suitable version simply continues with different paths instead of failing fatally when considering the first mismatch.
You will probably find CMake's guide on using dependencies helpful. It describes find_package and alternatives, and when each one is relevant / useful. Here's an excerpt from the section on find_package (italics added):
A package needed by the project may already be built and available at some location on the user's system. That package might have also been built by CMake, or it could have used a different build system entirely. It might even just be a collection of files that didn't need to be built at all. CMake provides the find_package() command for these scenarios. It searches well-known locations, along with additional hints and paths provided by the project or user. It also supports package components and packages being optional. Result variables are provided to allow the project to customize its own behavior according to whether the package or specific components were found.
find_package requires that the package provide CMake support in the form of specific files that describe the package's contents to CMake. Some library authors provide this support (the most desirable scenario for you, the package consumer), some don't but are prominent enough that CMake itself comes with such files for those packages, or in the worst case, there is no CMake support at all, in which case you can either do something to get the either of the previous good outcomes, or perform some kludges to get the job done (ie. define the targets yourself in your project's CMake config).
I'm currently having this issue with the Google Protobuf Library, but it is a recurring problem and will likely occur with many if not all 3rd-party packages that I want to build and install from source.
I'm developing for Windows, and we need to be able to generate both 32-bit and 64-bit versions of our DLLs. It was relatively straightforward to get CMake to install our own modules to architecture-specific subdirectories, e.g. D:\libraries\bin\i686 and d:\libraries\lib\i686 (and sim. for bin). But I'm having trouble achieving the same thing with 3rd-party libraries such as Protobuf.
I could, of course, use distinct CMAKE_INSTALL_PREFIX and CMAKE_PREFIX_PATH combinations (e.g. D:\libraries-i686 and D:\libraries-x86_64, and will probably end up doing just that, but it bothers me that there doesn't seem to be a better alternative. The docs for find_package() clearly show that the search procedure does attempt architecture-specific search paths, so why do the CMake files of popular libraries not generally seem to support installing to architecture-specific subdirectories?
Or could it be that it is just a matter of setting the right CMAKE_XXX variable?
Thanks to #arrowd for pointing me in the right direction, I now have my answer, though it is not exactly what I had hoped for.
CMAKE_LIBRARY_OUTPUT_DIRECTORY and CMAKE_RUNTIME_OUTPUT_DIRECTORY, however, specify the build output directories, not the install directories. As it turns out though, there are variables for the install directories too, called CMAKE_INSTALL_BINDIR and CMAKE_INSTALL_LIBDIR - they are actually plainly visible (along with plenty more) in the cmake-gui interface when "Advanced" is checked.
I tried setting those two manually (to bin\i686 and lib\i686), and it works: the Protobuf INSTALL target copies the files where I wanted to have them, i.e. where the CMake script of my consumer project will find them in an architecture-safe manner.
I'm not sure how I feel about this - I would have preferred something like a CMAKE_INSTALL_ARCHITECTURE or CMAKE_ARCHITECTURE_SUBDIR variable that CMake would automatically append to relevant install paths. The solution above requires overriding defaults that I would prefer to leave untouched.
Under the circumstances, my fallback approach might still be the better option. That approach however requires that the choice of architecture be made very early on, typically when running the script that initializes the CMake-specific environment variables that will be passed to cmake when configuring build directories. And it's worse when using cmake-gui, which requires the user to set all directories manually.
In the end, I'm still undecided.
I would like to create a script that will update files in the (default) install location with files from the source location where needed, based on the .wxs files that I have. I need to get this info from the wxs files, because the installation dir structure differs from the source location dir structure.
This would speed up my development cycle by not requiring a complete MSI uninstall/install when I have only recompiled one DLL for instance.
Is there functionality available in the Wix toolset that can give me a list of corresponding source and destination paths or would I have to implement everything including parsing of the Wix XML files myself?
I did not see anything relevant in the List of Tools section of the Wix documentation.
Alternative Approach: I would suggest using the commercial file and directory syncing and comparison tool Beyond Compare to copy files to the destination directory with ease if this is just for QA. I guess you can use post build steps too, but Beyond Compare is very nice and reliable. It has the features you need for just about anything related to comparison of files and folders (not affiliated). You can let the application just sit there and you can do a full comparison on the fly whenever needed. Essential software for deployment people. Alternatives exist of course (list).
I'm started to learn Free Pascal and stick to the simple yet important question: is it possible to create project in console Free Pascal IDE?
How could I compile two units into one program?
I've searched over Internet, but all links leads to the Lazarus, which is not the same thing as Free Pascal IDE...
My best clue would be is to use Makefiles, but as far as I can see, information on this is also very-very limited.
So how create and compile multi-unit Pascal programs in Free Pascal IDE then?
The textmode IDE has no project concept where a list of files is kept, OR any external build system.
Basically the autobuild capability of the compiler (that is built-in) is utilized, so pressing compile or build on the mainmodule(program) will compile the whole lot.
The main module can be set in compiler->primary file, so that compile will also work from non main modules.
However it is possible to have local IDE settings (primary file, directories, defines), by copying all fp.(cfg|dsk|ini) files from the FPC directory to your project dir, and then customizing them (from within the IDE).
One could regard the combination of a set of config files + a directory for the mainmodule as a project or solution.
I'm trying to understand the build process of a codebase. The project uses both autoconf (configure scripts that generate makefiles) and Maven.
I would like to be able identify all of the file dependencies in the project, so that for any output file that ends up being generated by a build, I can identify how it was actually produced. Ultimately, I'd like to generate a diagram using something like graphviz to visualize the dependencies, but for now I just want to extract them.
Is there any automated way to do this? In other words, given some makefiles and Maven or ant XML files, and the name of the top-level target, is there a way to identify all of the files that will be generated, the programs used to generate them, and the input files associated with those programs?
Electric Accelerator and ClearCase are two systems that do this, by running the build and watching what it does (presumably by intercepting operating system calls). This has the advantage of working for any tool, and being unaffected by buggy makefiles (hint: they're all buggy).
That's probably the only reliable way for non-trivial makefiles, since they all do things like generating new make rules on the fly, or have behaviour that depends on the existence of files on disk that are not explicitly listed in rules.
I don't know about the maven side, but once you've ./configured the project, you could grep through the output of make -pd (make --print-data-base --dry-run) to find the dependencies. This will probably be more annoying if it's based on recursive make, but still manageable.
Note that if you're using automake, it computes detailed dependencies as a side-effect of compilation, so you won't get all the dependencies on #included headers until you do a full build.