Quote:
Originally Posted by gnashley
I keep 2.95.3, 3.2.3, 3.3.6 around since I have a love affair with old GTK-1.2 software. And I'm still running Slack-11.0 for daily use(I also have a love affair with kernel-2.4.xx). Since Slack-11.0 uses gcc-3.4.6 as standard and I already have gcc-3.3.6 setup in another path, I compiled cmake to use gcc-3.3.6 to simulate what would happen on Slack-12.0 using gcc-3.4.6 in a side path. Does that even make sense?
Anyway, I just wanted to let you know about passing the -DCMAKE_INSTALL_PREFIX in case you want it when compiling manually. This is what I've made src2pkg do. Passing other defines doesn't seem to work so easily with src2pkg, but if you are using cmake manually you can easily pass other stuff like CMAKE_C_FLAGS.
|
Gnashley,
Now this is exactly the point that I was wanting to ask. If I put all of the various versions of gcc (or any other program source) into subdirectories of gcc (or any other program source you'd want to do this with), will all of those sources be automatically built and installed as a single package? If not, might you consider doing something with src2pkg, where the following occurs.
User manually does the following.
1. Untar the main source file.
2. Copy and untar the subordinate source(s) into the master directory.
3. Tar the collected sources into one single file.
4. Rename the new tarfile to reflect it collective nature: ie. tarname-collection.tar.gz
5. Now run src2pkg on the new tarfile.
It would be nice in keeping with this thinking, if src2pkg would automatically (as in a case with gcc) rename each of the enclosed sources $name$version (where the periods are completely removed from the version string). This would then create one large package as follows.
I AM ONLY USING GCC AS AN EXAMPLE!! So no one try raising issues about how this isn't the normal or proper way to do things. I am only using gcc as an example, because it too frequently is required in multiple versions to compile other software, as already noted here.
Depending on how you chose to do this.
1. gcc-collection would be the package name with a date as the version string.
2. Each of the gcc versions would then have gcc295, gcc323, gcc336 etc as their file names. Their libraries would show the same thing.
3. This system would also allow for the cross-compilation for multiple architectures as well. Since each architecture could be installed as follows:
>> gcc-collection-$date/
>> gcc-collection-$date/$arch/
>> gcc-collection-$date/$arch/2.95
>> gcc-collection-$date/$arch/3.2.3
>> gcc-collection-$date/$arch/3.3.6
>> gcc-collection-$date/$arch/4.1.2
>> gcc-collection-$date/$arch/4.2.2
Using a date as the version seems the most sensible thing to do. Or a revision number can be used if built from cvs or svn.
Yes, this would indeed create very large packages. But as I said, this is ONLY an example. There are many other (smaller) sources which can be combined into a single binary. Some of these are so small, that even when built for every possible arch, they would still be small.
I had been thinking about this for some time now. And came across it when I successfully compiled the Emboss package. The instructions were given for how to build all architectures in ONE single compilation, and installed as a single package. This is something I very much need to do, as I am building a true multiarch single-package system, for every arch included in the kernel.
1.2.1 Compiling For Multiple Architectures
====================================
You can compile the package for more than one kind of computer at the
same time, by placing the object files for each architecture in their
own directory. To do this, you must use a version of `make' that
supports the `VPATH' variable, such as GNU `make'. `cd' to the
directory where you want the object files and executables to go and run
the `configure' script. `configure' automatically checks for the
source code in the directory that `configure' is in and in `..'.
And this from the multiarch build for Bash:
====================================
Alternatively, if your system supports symbolic links, you can use the `support/mkclone' script to create a build tree which has symbolic links back to each file in the source directory. Here's an example that creates a build directory in the current directory from a source directory `/usr/gnu/src/bash-2.0':
bash /usr/gnu/src/bash-2.0/support/mkclone -s /usr/gnu/src/bash-2.0 .
So if this is something that can be accomplished with src2pkg, I for one would like to see it done. I am also interested in whether or not SCons could be used as the build mechanism for src2pkg. If it is an advanced as described, it might be a better candidate.
Xavian-Anderson Macpherson
Shingoshi
