I have a large project which contains many libraries that the main binary depends on. I would like to know what the proper way to handle this in launchpad so I can build the libraries, then the main binary and offer each debian pacakge on a ppa.
You can see the project in question at lp:snapcpp (https://code.launchpad.net/snapcpp/). In snacpp, we have "snapwebsites", a C++ CMS system which attaches to a Cassandra database via our library "libQtCassandra." "snapwebsites" depends on libQtCassandra, as it does libltd, and others. Each of these libraries need to be separate debian packages themselves. Each project has its own "debian" folder but there is no root debian folder at this time.
How can I get this to work on launchpad, which requires a root debian folder? Do I need to construct a debian project at the root that lists each dependency? If not, do I need to break up each project into its own branch using bzr? If I do the latter, how do I call out those depencency debs for the build (in other words, how do I tell the recipe for snapwebsites that it needs to have libQtCassandra and its dependency packages installed)?
Thanks!
The solution that I discovered on my own was to utilize the recipe command "nest-part," which allows you to take a single folder out of a bzr branch and map it into your project. It cannot, however, map to the root of your branch.
What I did was to create a branch with only packaging information in it, and a CMakeLists.txt file containing "add_subdirectory(src)". Then I map from the main code branch (lp:snapcpp), but only the project in question. For example, here is the recipe for the "controlled_vars" project in snapcpp:
# bzr-builder format 0.3 deb-version {debupstream}+{revno}
lp:~snapcpp/snapcpp/controlled_vars
nest-part src lp:snapcpp controlled_vars src
There does need to be a branch with packaging information with each sub-project, but this is a one-time set up issue.
Related
I maintain a commercial, binary package for debian, ubuntu, & etc. and have gotten complaints about "bad package quality" from the Ubuntu installer. The root cause of this appears to be that the package installs files in the /opt and /etc/opt directories which apparently throws lintian into a hissy fit. As I understand the purpose of these directories, they are meant to serve the needs of "Add-on" applications although I have yet to see any definition of what "add-on" is supposed to mean. I have attempted to create a lintian override file for my package in the /usr/share/lintian/overrides directory and, when I do so, I get the following report from Lintian:
N: Some overrides were ignored, since the tags were marked "non-overridable".
N: The following tags were "non-overridable" and had at least one override
N: - dir-or-file-in-opt
Is there any way around this apparent obstinacy?
If you're using debhelper to build your package, lintian overrides for the binary packages should go in the debian folder with the filename [package].lintian-overrides. This ensures the overrides make it into the proper directory on package installation. (For source packages, overrides go in the file debian/source/lintian-overrides.)
That said, short of not putting your files in /opt, I'm not sure there's a way to completely get rid of the dir-or-file-in-opt lintian complaint. Though, I'm not sure it's necessary since, to my knowledge, the ubuntu/aptdaemon lintian profile (which disables the dir-or-file-in-opt tag) is used in most of the situations in which lintian would be run automatically during/before package installation. That's probably not quite the answer you were hoping for, but I hope it's helpful nonetheless!
Sources:
Debian New Maintainers' Guide, section 5.14
Lintian User's Manual, section 2.4
Cendio ThinLinc bug #5232
I realise this is a newb question but I've been racking my brains for hours.
So I want to use the STK (Synthesis Toolkit) to generate sine waves etc. I've downloaded the source files from https://ccrma.stanford.edu/software/stk/download.html
I unzipped the tar.gz using 7zip.
I opened up the demo.cpp project file (under /projects/demo/demo.cpp) and whenever I try to compile it, I receive lots of errors, all starting with "undefined reference to"
I have set the compiler search directory to include the root folder of the stk kit (unzipped as "stk-4.5.0"). My understanding is that I also have to find file for the linker, that is of the type .lib? Is that correct? I haven't been able to find a .lib file to link to.
I feel like this is a simple fix - what am I missing?
You've downloaded a source , not the compiled library which might be used by linker (.lib file) There are three solutions:
1. Compile whole src folder of your download ( see instructions on their website). Frankly, I've tried to do that recently but failed, especially under Windows although I don't have any experience in this so you can try yourself.
2. Use precompiled library available in some Linux repositories. I had success with Slacko Puppy linux. Package simply adds libstk.a (linux static library) to /usr/lib and stk headers to /usr/include/stk (notice you have to add exactly that path to compiler, since /usr/lib is not enough). This gave me best results.
3. If you use only several classes, you can copy their .cpp files directly to your project source folder. Remember to add parent classes, too (see STK site -> Classes). Again I recommend that you give the compiler path to include folder you've unzipped, but copying only selected headers should also work.
I've found this article helpful (see also A1): http://www.learncpp.com/cpp-tutorial/a3-using-libraries-with-codeblocks/
Hope I've helped
Greetings, what I'm trying to do is to port an existing Windows application to Linux using CMake with CMakeLists, which I generated with the vcproj2cmake Script (https://github.com/sixman9/vcproj2cmake).
With the CMakeLists.txt and CMake I was able to successfully port a VS 2005 project to VS 2010. Now I try to port the same VS 2005 project to Linux, so that I can edit it with KDevelope.
The project itself is small and I think it would be easier to just create a new project and copy all relevant files (if that would work), the problem is, that it's not only one project but many, hence I was looking for a way to port a project in an as simple as possible way.
In Linux I was able to create a CMakeLists.txt using the vcproj2cmake script. The next step would be creating a KDevelope project using CMake. And this is where I'm stuck.
Everytime I try to run CMake I get the following error:
CMake Error at CMakeLists.txt: 196 (set_property) :
set_property could not find TARGET Test_Project. Perhaps it has not yet been
created.
Test_Project: installing /root/Desktop/Test_Project/vs8/CMakeLists. txt rebuilder (watching /root/Desktop/Test_Project/vs8/Test_Project. vcproj)
Configuring incomplete, errors occurred!
See also “/root/Desktop/Test_Project/vs8/CMakeFiles/CMakeOutput.log”.
I searched for a solution or an approach for quite a time now, but the only results that I get are project-specific, or at least I think they are.
Content of the CMakeLists.txt from line 196:
set_property(TARGET Test_Project PROPERTY PROJECT_LABEL "Test_Project")
v2c_rebuild_on_update(Test_Project "${CMAKE_CURRENT_SOURCE_DIR}/Test_Project.vcproj" ${CMAKE_CURRENT_LIST_FILE} "vcproj2cmake.rb" ".")
include(${V2C_HOOK_POST} OPTIONAL)
Perhaps there are more efficient ways to port many projects form Windows to Linux, I'm open for any suggestion.
It is a bit difficult to help without having your project - since you are using a third party tool to convert a VC project you should ask the author of that tool. :D
If you have many projects which you are going to maintain, I suggest that you select one where you can create a cross platform (Windows/Linux) CMake config for which you can reuse for other projects.
Most of the config should be the same for all platforms you are building for - the difference should be which generator is used and what libraries to link in the final executable (if you are building one that is). The generator is specified when running cmake.
In my opinion you should try an out of source build with the following structure:
/$COMMON_DIR/CMakeLists.txt
/CMakeLists.txt
/src/
/build/
/build/vcX
/build/generate_vcX.bat
/build/linux
/build/generate_linux.sh
$COMMON_DIR should contain the CMake code you expect to be common for all you projects - like a function to create a static library for a module which searches for files in /src and another function which can be used to add an executable for certain platform.
The CMakeLists.txt in the root of your project (repository, I assume) should call the functions defined in $COMMON_DIR and possibly add some project specific defines or link flags.
I have developed a module (M.hs) which depends upon 3 other modules (A.hs, B.hs and C.hs). Now I want to use the module M across multiple other projects. So I have to install this module. But for learning purpose I don't want to use cabal, I want to do it manually. I want to install it in my home dir.
What is a proper course of action? Which files to be created, copied? where? How to use this module in other project?
Additional info:
I am using Debian 6
I am using GHC 6.12
You say you don’t want to use cabal, but would you use Cabal?
cabal is the name of the command line tool provided by cabal-install which can download packages from Hackage and resolve dependencies.
Cabal is the library that Haskell code uses to drive the compilation (e.g. pre-process files, build in the right order, build variants, generate documentation) and install into the right location.
I would not recommend not using Cabal, even for learning purposes, until you want to write a replacement for it. But if you really want to do it, here is the rough outline, with enough details to figure out for a good learning experience:
Build your files with -package-name yourpkgname-version.
Link the generated files to form a libyourpkgname-version.a file.
Create a package configuration file like /var/lib/ghc/package.conf.d/mtl-2.1.2.conf, and pay attention to name, `exposed-modules, import-dirs, library-dirs and hs-libraries
Register package by passing it to ghc-pkg register
In this instance I'm using c with autoconf, but the question applies elsewhere.
I have a glade xml file that is needed at runtime, and I have to tell the application where it is. I'm using autoconf to define a variable in my code that points to the "specified prefix directory"/app-name/glade. But that only begins to work once the application is installed. What if I want to run the program before that point? Is there a standard way to determine what paths should be checked for application data?
Thanks
Thanks for the responses. To clarify, I don't need to know where the app data is installed (eg by searching in /usr,usr/local,etc etc), the configure script does that. The problem was more determining whether the app has been installed yet. I guess I'll just check in install location first, and if not then in "./src/foo.glade".
I dont think there's any standard way on how to locate such data.
I'd personally do it in a way that i'd have a list of paths and i'd locate if i can find the file from anyone of those and the list should containt the DATADIR+APPNAME defined from autoconf and CURRENTDIRECTORY+POSSIBLE_PREFIX where prefix might be some folder from your build root.
But in any case, dont forget to use those defines from autoconf for your data files, those make your software easier to package (like deb/rpm)
There is no prescription how this should be done in general, but Debian packagers usually installs the application data somewhere in /usr/share, /usr/lib, et cetera. They may also patch the software to make it read from appropriate locations. You can see the Debian policy for more information.
I can however say a few words how I do it. First, I don't expect to find the file in a single directory; I first create a list of directories that I iterate through in my wrapper around fopen(). This is the order in which I believe the file reading should be done:
current directory (obviously)
~/.program-name
$(datadir)/program-name
$(datadir) is a variable you can use in Makefile.am. Example:
AM_CPPFLAGS = $(ASSERT_FLAGS) $(DEBUG_FLAGS) $(SDLGFX_FLAGS) $(OPENGL_FLAGS) -DDESTDIRS=\"$(prefix):$(datadir)/:$(datadir)/program-name/\"
This of course depends on your output from configure and how your configure.ac looks like.
So, just make a wrapper that will iterate through the locations and get the data from those dirs. Something like a PATH variable, except you implement the iteration.
After writing this post, I noticed I need to clean up our implementation in this project, but it can serve as a nice start. Take a look at our Makefile.am for using $(datadir) and our util.cpp and util.h for a simple wrapper (yatc_fopen()). We also have yatc_find_file() in case some third-party library is doing the fopen()ing, such as SDL_image or libxml2.
If the program is installed globally:
/usr/share/app-name/glade.xml
If you want the program to work without being installed (i.e. just extract a tarball), put it in the program's directory.
I don't think there is a standard way of placing files. I build it into the program, and I don't limit it to one location.
It depends on how much customising of the config file is going to be required.
I start by constructing a list of default directories and work through them until I find an instance of glade.xml and stop looking, or not find it and exit with an error. Good candidates for the default list are /etc, /usr/share/app-name, /usr/local/etc.
If the file is designed to be customizable, before I look through the default directories, I have a list of user files and paths and work through them. If it doesn't find one of the user versions, then I look in the list of default directories. Good candidates for the user config files are ~/.glade.xml or ~/.app-name/glade.xml or ~/.app-name/.glade.xml.