I'm trying to configure Eclipse CDT 2019-12 to build an old project that uses autotools. There is an autogen.sh script, but it is not included in the directory which holds configure.ac and the other source files. Looking at the Eclipse Autotools user guide, that might be the reason why running 'Reconfigure project' does not use autogen.sh. but runs autoreconf.
I redefined Autotools > Configure Settings > autogen > Command to use a relative path, but that didn't help. Redefining Autotools > General > Tools Settings > autoreconf leads to an internal error (NullPointerException).
What can I do to help Eclipse find and execute the off source directory autogen.sh?
The directory containing configure.ac, and therefore where the configure script also resides and / or is created, is the root of the project's source tree by definition. In a well-formed Autotools project, there should not be any build system artifacts outside the source tree because the contents of the source tree define what gets packaged and distributed.
Moreover, it is my understanding and recollection that Eclipse relies on that in defining its logical view of an Autotools project. Eclipse goes to some trouble to try to prevent project building from accessing files outside the spaces specified in the project configuration. It does not particularly surprise me that it does not recognize an autogen.sh file outside the source tree, no matter how you try to specify its location.
First off, it would be worthwhile examining the autogen script to determine whether it's actually doing anything needful that autoreconf does not do, or if it may be intentionally omitting anything that autoreconf does. It may be that letting Eclipse use autoreconf instead of autogen.sh will work just fine.
If in fact you need Eclipse to use autogen.sh, then your best bet is probably to copy it into the source directory and update the copy appropriately for its new location.
Related
Is it possible to configure a Bazel custom toolchain to include directories in the repository?
Assume that I have following in the root of my repository:
sysroots/armhf/include/myheader.h
sysroots/amd64/include/myheader.h
myproject1/component.cpp
myproject2/component.cpp
I'd like to configure toolchain such that when I run bazel build --config armhf, component.cpp files including myheader.h would get the header from sysroot/armhf/include directory, and when I run bazel build --config amd64, file from corresponding sysroot/amd64 directory were used.
This needs to work without having to modify projects containing component.cpp files.
Essentially I would like to check in platform specific headers and binaries in the source repository along with the code.
If you haven't found it yet, you need to write C++ toolchains. The Configure C++ Toolchains Tutorial is a good place to start, if you have more specific questions they'll get better answers as separate questions. I'm going to answer specifically about the paths here.
Most of the paths are just normal paths relative to the execution root. That typically means external/<repo_name>/<package>/<name> for paths in external repositories, or just <package>/<name> for paths in the main repository. bazel-toolchain's pkg_path_from_label function implements this logic, for example. In your case, that's sysroots/armhf/include for the first path.
cxx_builtin_include_directories is special. Paths there have unique syntaxes to generate absolute paths. The relevant one looks like "%package(#your_toolchain//relative/clang/include)%", with #your_toolchain replaced with your repository's name. In your case that means something like "%package(#//sysroots/armhf)%/include/myheader.h". Depending on where the package boundary is (deepest folder with a BUILD file) more or less of that might need to be in the %package() part.
Those directives get expanded when generating compiler command lines. I'm not aware of any documentation besides the source.
I have a cmake project that successfully builds locally but errors with
include could not find load file:
CmakeDependentOption
when trying to build on a CI platform or in Docker. Note that CMakeDependentOption.cmake is a script that comes with cmake itself. So it should just be available. On CI to install cmake, I wget the relevant cmake release from their downloads page, unzip it and add the bin directory to the PATH environment variable. Then I use the cmake command to build my library. The result is the above error.
I suspect this means that a CMake variable (such as "CMAKE_MODULE_PATH" but not, since this variable seems to be empty at the start of the cmake script) is messed up or not set somehow. The path to the correct file to include is
<cmake_root>/share/cmake-3.18/Modules/CMakeDependentOption.cmake
And I have verified that it exists manually. My question: is there a way to locate this directory from within cmake? Perhaps a cmake --config or cmake --libs mode (a bit like pkg-config?)
Failing that, does anybody have any suggestions as to why this is happening and how to get around it.
You can locally because most likely you don't use a linux based platform, like windows or mac. This is because linux filesystem are case sensitive. Which means CmakeDependentOption is different from CMakeDependentOption.
Docker runs containers in linux, so filenames are gonna be case sensitive, and the include is going to fail if the cases are different.
I try to compile an eclipse-project written in c++ which is building a .so-File. Now i try to build the project without an IDE. I tried it with MinGW but the created .so doesn't work. I think there are used some special packages but how can I get the information's.
Is there a way to Export the build settings and import them into MinGW?
How can i else set the compiler?
This is the ToolChainEditor which i would recreat in MinGW.
You can't import a configuration into mingw, but you can tell mingw where to find a configuration of sorts.
Eclipse can be configured to generate a makefile (At least as recent as Neon). Select your project and use the main menu to navigate Project->Properties->C/C++ Build->Tool Chain Editor. Set the "Current builder" to Gnu Make Builder and build the project.
In the generated folder where you would find the finished executable you will find three more files: makefile, objects.mk and sources.mk and can use the make utility that often comes with mingw. It can also be downloaded separately if you have to.
From the command line, enter the folder and type make. Magic will happen. If you want to know more about the magic, make is a very deep topic well worth learning, even if only as a gateway drug to more modern build systems that descended from it.
I have a problem using libclang:
I built libclang locally. It resides somewhere like clang-llvm/…/libclang.3.4.dylib.
Then I developed a foundation tool using that dylib. (exactly: I copied a version to my project folder and linked against this.) The foundation tool works fine. But, of course, at load time it uses the dylib in my local build folder. This is unacceptable, because the user of the tool has to install clang to use my tool.
So I copied libclang.3.4.dylib to a location inside /usr/…/libclang.3.4.dylib and changed the installation path to that location using install_name_path -id /usr/…/libclang.3.4.dylib /usr/…/libclang.3.4.dylib.
After that my tool finds the dylib there but does not work since the parser cannot find stdarg.h any more in the file, that is parsed by my tool.
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:12:10: fatal error: 'stdarg.h' file not found
How can I set the installation path of libclang.3.4.dylib to something public?
Amin, my good friend.
<sarcasm>
From what you wrote it should be OBVIOUS to EVERYONE that you have to create a release build of your tool and NOT a debug build. Xcode should have told you that in the form of CLEAR and EASY to understand error messages.
</sarcasm>
Solution: Use a release build of your tool instead of a debug build.
:)
I'm using Eclipse-CDT to develop and compile projects for Linux. As host both Linux or Windows may be used.
The project is created as Makefile project with a special build command, so I changed the build-command from make to our special one and the "Build" and "Clean" commandline approbriately. The build command uses a gcc from a directory not in $PATH, because the whole compiler-suite is located in the version control system. (Correct $PATH is set by the build command.)
This works fine under Linux: Eclipse learns the Symbols and Include Files automatically.
However, under Windows the Symbols are recognized, but the Include Paths aren't.
When I have a look in the generated MyProject.sc file in the workspace/.metadata/.plugins/org.eclipse.cdt.make.core directory, I see that the Include-Files are recognized, but prepended with a C:\cygwin.
The GCC command line uses absolute paths without the Drive letter.
(The whole source tree is located on a special Drive (e.g. W:), CWD is on this drive ).
E.g. gcc/g++ is invoked with -I /net_libs/lib1/inc and Eclipse recognizes C:\cygwin\net_libs\lib1\inc.
BTW: The standard-include paths are recognized correctly (e.g. W:/toolchain/win32/i686-pc-linux-gnu/include/c++/4.2.1).
The Build-Directory is set to the directory of the Makefile which is on the same Drive as the Sources and Includes.
I tried various "Toolchain" settings (Cygwin, MinGw, Linux gcc), the result is same every time. (After changing the settings, I even stopped Eclipse, deleted the sc file and started Eclipse again).
I don't know why Eclipse knows about my Cygwin installation in C:\Cygwin - the installation is NOT used by the compiler or related tools.
When I change the .sc file manually and correct the paths and restart Eclipse, everything works fine.
Do you have any hints what may be the problem?
Have a look at Project->Propterties->C/C++ Build->Discovery Options.
There is a Compiler invocation command - usually set to gcc, which means "gcc in PATH". Try setting this to your gcc from your build system.