U++ framework
Do not panic. Ask here before giving up.

Home » Developing U++ » Releasing U++ » Working on new release system...
Working on new release system... [message #20365] Sat, 14 March 2009 12:09 Go to next message
mirek is currently offline  mirek
Messages: 14290
Registered: November 2005
Ultimate Member
I have started much needed work on new flexible release system, I have decided to put some description and notes here, as sort of "release system blog".

First, Win32 build system.

It will be supposed to run on "U:" drive, with "U:\upp.src" being the svn trunk.

Build method used will MSC9.

Now important think, also for other releases. We need to finally have some means describing what belongs to the release. That is why
in U:\upp.src\uppsrc (which is normal svn uppsrc) folder are now files:

packages - contains a list of subdirectories of u:\uppsrc\uppsrc that are supposed to be in release, including "deep" subdirectories

packages1 - same, but without subdirectories

assemblies - list of assemblies to put into release excluding uppsrc (means, examples, reference, tutorial, bazaar).

(more to follow... Smile
Re: Working on new release system... [message #20367 is a reply to message #20365] Sun, 15 March 2009 01:00 Go to previous messageGo to next message
tojocky is currently offline  tojocky
Messages: 607
Registered: April 2008
Location: UK
Contributor

luzr wrote on Sat, 14 March 2009 13:09

I have started much needed work on new flexible release system, I have decided to put some description and notes here, as sort of "release system blog".

First, Win32 build system.

It will be supposed to run on "U:" drive, with "U:\upp.src" being the svn trunk.

Build method used will MSC9.
... Smile


How about to ask the user where need unpack upp.src? By default will be nice in "U:\upp.src". Same situation will be nice add for examples, reference, tutorial and bazaar! Not only for MyApps!
Re: Working on new release system... [message #20370 is a reply to message #20367] Sun, 15 March 2009 13:34 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14290
Registered: November 2005
Ultimate Member
tojocky wrote on Sat, 14 March 2009 20:00

luzr wrote on Sat, 14 March 2009 13:09

I have started much needed work on new flexible release system, I have decided to put some description and notes here, as sort of "release system blog".

First, Win32 build system.

It will be supposed to run on "U:" drive, with "U:\upp.src" being the svn trunk.

Build method used will MSC9.
... Smile


How about to ask the user where need unpack upp.src? By default will be nice in "U:\upp.src". Same situation will be nice add for examples, reference, tutorial and bazaar! Not only for MyApps!



User? What user? This work is for U++ infrastructure server...

Mirek
Re: Working on new release system... [message #20430 is a reply to message #20370] Wed, 18 March 2009 11:36 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14290
Registered: November 2005
Ultimate Member
Nightly builds should now be working.

The key point to define builds is in svn:

uppbox/Scripts/all

and this script calls several subscripts to perform builds. As there is standard build environment and wine, script can compile U++ projects and use them as tools...

The output of the process is implemented as:

- build script or code stores files that is to be uploaded to "~/upload" directory

- then performs ~/bin/upload

Mirek

[Updated on: Wed, 18 March 2009 11:36]

Report message to a moderator

Re: Working on new release system... [message #21830 is a reply to message #20430] Sun, 07 June 2009 22:31 Go to previous messageGo to next message
cbpporter is currently offline  cbpporter
Messages: 1428
Registered: September 2007
Ultimate Contributor
One question: the automated build system is great and all, but why have only sources, Windows exe and 64-bit Debian. For starters, couldn't we have 32 bit debs also for the ones that didn't climb on to the 64 bit wagon yet.

And a RPM would be great also. I know that with RPMs it is a lot more difficult, since there is not single distro to target, but with just a little luck and no automatic dependency management we could get a fairly general RPM. There were posts with scripts that worked very well for specific distros. Couldn't we integrate these in the automatic build process?
Re: Working on new release system... [message #21831 is a reply to message #21830] Sun, 07 June 2009 22:45 Go to previous messageGo to next message
andrei_natanael is currently offline  andrei_natanael
Messages: 262
Registered: January 2009
Experienced Member
The problem is for 32bit build because it's not that easy to have a 32bit environment on 64bit system. I know it's simple with chroot or bootstrap but the final executable will link with 64 bit ld-linux-x86-64.so, even if you build your program with 32bit option. It may be some options out there but are hard to implement.
Re: Working on new release system... [message #21835 is a reply to message #21830] Sun, 07 June 2009 23:47 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14290
Registered: November 2005
Ultimate Member
cbpporter wrote on Sun, 07 June 2009 16:31

One question: the automated build system is great and all, but why have only sources, Windows exe and 64-bit Debian. For starters, couldn't we have 32 bit debs also for the ones that didn't climb on to the 64 bit wagon yet.

And a RPM would be great also. I know that with RPMs it is a lot more difficult, since there is not single distro to target, but with just a little luck and no automatic dependency management we could get a fairly general RPM. There were posts with scripts that worked very well for specific distros. Couldn't we integrate these in the automatic build process?


I would be happy for supporting more targets, but that requires maintainers.

Perhaps we could release more targets for "major" releases? - Those announced on sf.net, and upload there as well?

Mirek
Re: Working on new release system... [message #21844 is a reply to message #21835] Mon, 08 June 2009 10:36 Go to previous messageGo to next message
koldo is currently offline  koldo
Messages: 3458
Registered: August 2008
Senior Veteran
Hello all

I have updated Ubuntu 32 in my computer so if you give me the script to do .deb, I can make them and upload where and when necessary.

Best regards
Koldo


Best regards
Iñaki
Re: Working on new release system... [message #21850 is a reply to message #21844] Mon, 08 June 2009 12:07 Go to previous messageGo to next message
andrei_natanael is currently offline  andrei_natanael
Messages: 262
Registered: January 2009
Experienced Member
koldo wrote on Mon, 08 June 2009 11:36

Hello all

I have updated Ubuntu 32 in my computer so if you give me the script to do .deb, I can make them and upload where and when necessary.

Best regards
Koldo


Scripts exists in svn in linux_scripts.
Re: Working on new release system... [message #21875 is a reply to message #21850] Mon, 08 June 2009 23:35 Go to previous messageGo to next message
koldo is currently offline  koldo
Messages: 3458
Registered: August 2008
Senior Veteran
Hello all

Well, Massimo Del Fedele has done the scripts and are ready to be used.

So If it is ok for you every release announcement -about every two weeks- I can get the Google Code .tar.gz and from that to get the 32 bits .deb and upload it to SF or other place.

If there is no opinion against it I will do it on next announcement.

Best regards
Koldo


Best regards
Iñaki
Re: Working on new release system... [message #21891 is a reply to message #21875] Tue, 09 June 2009 15:08 Go to previous messageGo to next message
cbpporter is currently offline  cbpporter
Messages: 1428
Registered: September 2007
Ultimate Contributor
Specific build are fine, but they are some extra work for specific individuals. Having it automated would be better.

Wouldn't it be possible to run a virtual 32 bit machine on the build machine and it would generate the build? This would work if the build machine is a server which is always running.
Re: Working on new release system... [message #21938 is a reply to message #21891] Thu, 11 June 2009 19:30 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14290
Registered: November 2005
Ultimate Member
cbpporter wrote on Tue, 09 June 2009 09:08

Specific build are fine, but they are some extra work for specific individuals. Having it automated would be better.

Wouldn't it be possible to run a virtual 32 bit machine on the build machine and it would generate the build? This would work if the build machine is a server which is always running.



Well, virtual machine is somewhat more diffult, but possible.

Anyway, I still believe it should be possible to build it without VMs... If I can build win32 version on ubuntu64, I guess ubuntu32 should be possible as well....

Mirek
Re: Working on new release system... [message #21946 is a reply to message #20365] Thu, 11 June 2009 23:08 Go to previous messageGo to next message
cocob is currently offline  cocob
Messages: 156
Registered: January 2008
Experienced Member
what about gcc -m32 ?
Re: Working on new release system... [message #21947 is a reply to message #21946] Thu, 11 June 2009 23:09 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14290
Registered: November 2005
Ultimate Member
cocob wrote on Thu, 11 June 2009 17:08

what about gcc -m32 ?


I believe that should work.

Anyway, there are still problems:

- libraries

- .deb

Mirek
Re: Working on new release system... [message #21954 is a reply to message #21831] Fri, 12 June 2009 08:22 Go to previous messageGo to next message
andrei_natanael is currently offline  andrei_natanael
Messages: 262
Registered: January 2009
Experienced Member
luzr wrote on Fri, 12 June 2009 00:09

cocob wrote on Thu, 11 June 2009 17:08

what about gcc -m32 ?


I believe that should work.
Mirek

andrei_natanael wrote on Sun, 07 June 2009 23:45

the final executable will link with 64 bit ld-linux-x86-64.so, even if you build your program with 32bit option.

I've tried to build theide with -m32 option for 32bit but it's still linking with 64 bit version of ld-linux-x86-64.so as i said in a previous post. I think it's possible not to link with it but you will loose the dynamic loading of *.so, it means that we will not be able to use DLI for runtime.
Re: Working on new release system... [message #22037 is a reply to message #20365] Mon, 15 June 2009 09:00 Go to previous messageGo to next message
koldo is currently offline  koldo
Messages: 3458
Registered: August 2008
Senior Veteran
Hello all

I have seen your efforts to get a 32 bit .deb.

Waiting for having that automated, I think that we would have to do it manually.

I agree that automated builds is the best solution, but meanwhile the worst solution is to have no 32 bits build at all.

Best regards
Koldo


Best regards
Iñaki
Re: Working on new release system... [message #22048 is a reply to message #22037] Mon, 15 June 2009 14:31 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14290
Registered: November 2005
Ultimate Member
koldo wrote on Mon, 15 June 2009 03:00

Hello all

I have seen your efforts to get a 32 bit .deb.

Waiting for having that automated, I think that we would have to do it manually.

I agree that automated builds is the best solution, but meanwhile the worst solution is to have no 32 bits build at all.

Best regards
Koldo


Maybe we could limit nightly builds to win32 / src and upload various versions to sf.net only by maintainers?

Mirek
Re: Working on new release system... [message #22079 is a reply to message #21954] Tue, 16 June 2009 21:20 Go to previous messageGo to next message
cocob is currently offline  cocob
Messages: 156
Registered: January 2008
Experienced Member
Do you use -m32 for linking stage ?
The 32 bit libs are installed ?

cocob
Re: Working on new release system... [message #22253 is a reply to message #20365] Sat, 27 June 2009 23:51 Go to previous messageGo to next message
amrein is currently offline  amrein
Messages: 278
Registered: August 2008
Location: France
Experienced Member
For rpm automatic release, we need a script to generate standard Makefile without theide.

Ultimate++ still doesn't have a great command line configure/build system like cmake, automake/autoconf, ant or qmake/tmake. I understood that you didn't want extra dependencies.

Are you searching for / wanting a bash script that compute .upp files to generate Makefiles?
Re: Working on new release system... [message #22254 is a reply to message #20365] Sun, 28 June 2009 00:11 Go to previous messageGo to next message
amrein is currently offline  amrein
Messages: 278
Registered: August 2008
Location: France
Experienced Member
Virtual machines are the easier way to have a complete and good automatic build/test system. Already said this a few months ago.

On Linux or Windows, try http://www.virtualbox.org

Just share a directory in your VMs with read/write access, add needed packages, add a script in your VM to automatically copy and build your new source code from this shared directory and save the binary and logs in this directoy, do a snapshot and then run the VMs with VirtualBox command line tools.

To have up to date Linux release, the script should be able to get updates and then halt the VM before doing a new snapshot with the VirtualBox command line tool (if the script see a "doupdate" file in the shared directory for example).

With multiple VM and with a correct configuration script supporting .upp files configuration, pkg-config and default build directories, all will be automated for good and you will be able to release src, rpm, deb, pkg, exe, 32 bit packages, 64 packages, whatever.

[Updated on: Sun, 28 June 2009 08:53]

Report message to a moderator

Re: Working on new release system... [message #22328 is a reply to message #20365] Fri, 03 July 2009 19:02 Go to previous messageGo to next message
andrei_natanael is currently offline  andrei_natanael
Messages: 262
Registered: January 2009
Experienced Member
This week i've tried to make a chroot of Ubuntu Jaunty 32bit and build an U++ app from it. The size of chroot is 647.2 MB, but with care it can be reduced. What chroot say about the application:
Quote:

can@can-laptop :~/chroot/jaunty/home/can/upp-svn/out/GCC.Debug.Debug_full.G ui.Shared$ ls
AddressBookXML2
can@can-laptop :~/chroot/jaunty/home/can/upp-svn/out/GCC.Debug.Debug_full.G ui.Shared$ file AddressBookXML2
AddressBookXML2: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, not stripped
can@can-laptop :~/chroot/jaunty/home/can/upp-svn/out/GCC.Debug.Debug_full.G ui.Shared$
can@can-laptop :~/chroot/jaunty/home/can/upp-svn/out/GCC.Debug.Debug_full.G ui.Shared$ ldd AddressBookXML2
linux-gate.so.1 => (0xf7f4f000)
libgtk-x11-2.0.so.0 => /usr/lib32/libgtk-x11-2.0.so.0 (0xf7b83000)
libgdk-x11-2.0.so.0 => /usr/lib32/libgdk-x11-2.0.so.0 (0xf7af6000)
libatk-1.0.so.0 => /usr/lib32/libatk-1.0.so.0 (0xf7ada000)
libgdk_pixbuf-2.0.so.0 => /usr/lib32/libgdk_pixbuf-2.0.so.0 (0xf7ac0000)
libpangocairo-1.0.so.0 => /usr/lib32/libpangocairo-1.0.so.0 (0xf7ab4000)
libfontconfig.so.1 => /usr/lib32/libfontconfig.so.1 (0xf7a87000)
libXext.so.6 => /usr/lib32/libXext.so.6 (0xf7a77000)
libXrender.so.1 => /usr/lib32/libXrender.so.1 (0xf7a6c000)
libXinerama.so.1 => /usr/lib32/libXinerama.so.1 (0xf7a69000)
libXi.so.6 => /usr/lib32/libXi.so.6 (0xf7a5f000)
libXrandr.so.2 => /usr/lib32/libXrandr.so.2 (0xf7a57000)
libXcursor.so.1 => /usr/lib32/libXcursor.so.1 (0xf7a4e000)
libXfixes.so.3 => /usr/lib32/libXfixes.so.3 (0xf7a48000)
libpango-1.0.so.0 => /usr/lib32/libpango-1.0.so.0 (0xf7a05000)
libcairo.so.2 => /usr/lib32/libcairo.so.2 (0xf798b000)
libX11.so.6 => /usr/lib32/libX11.so.6 (0xf789c000)
libgobject-2.0.so.0 => /usr/lib32/libgobject-2.0.so.0 (0xf785e000)
libgmodule-2.0.so.0 => /usr/lib32/libgmodule-2.0.so.0 (0xf7859000)
libglib-2.0.so.0 => /usr/lib32/libglib-2.0.so.0 (0xf77a0000)
libdl.so.2 => /lib32/libdl.so.2 (0xf779c000)
libXft.so.2 => /usr/lib32/libXft.so.2 (0xf7788000)
libpthread.so.0 => /lib32/libpthread.so.0 (0xf776f000)
libz.so.1 => /usr/lib32/libz.so.1 (0xf7759000)
libpng12.so.0 => /usr/lib32/libpng12.so.0 (0xf7733000)
libstdc++.so.6 => /usr/lib32/libstdc++.so.6 (0xf7643000)
libm.so.6 => /lib32/libm.so.6 (0xf761d000)
libgcc_s.so.1 => /usr/lib32/libgcc_s.so.1 (0xf760e000)
libc.so.6 => /lib32/libc.so.6 (0xf74ab000)
libXcomposite.so.1 => /usr/lib32/libXcomposite.so.1 (0xf74a7000)
libXdamage.so.1 => /usr/lib32/libXdamage.so.1 (0xf74a4000)
libgio-2.0.so.0 => /usr/lib32/libgio-2.0.so.0 (0xf7435000)
libpangoft2-1.0.so.0 => /usr/lib32/libpangoft2-1.0.so.0 (0xf740c000)
libfreetype.so.6 => /usr/lib32/libfreetype.so.6 (0xf7395000)
libexpat.so.1 => /usr/lib32/libexpat.so.1 (0xf736e000)
libXau.so.6 => /usr/lib32/libXau.so.6 (0xf7369000)
libpixman-1.so.0 => /usr/lib32/libpixman-1.so.0 (0xf7326000)
libdirectfb-1.0.so.0 => /usr/lib32/libdirectfb-1.0.so.0 (0xf72c0000)
libfusion-1.0.so.0 => /usr/lib32/libfusion-1.0.so.0 (0xf72b7000)
libdirect-1.0.so.0 => /usr/lib32/libdirect-1.0.so.0 (0xf72a2000)
libxcb-render-util.so.0 => /usr/lib32/libxcb-render-util.so.0 (0xf729c000)
libxcb-render.so.0 => /usr/lib32/libxcb-render.so.0 (0xf7294000)
libxcb.so.1 => /usr/lib32/libxcb.so.1 (0xf727a000)
libpcre.so.3 => /lib32/libpcre.so.3 (0xf7248000)
/lib/ld-linux.so.2 (0xf7f50000)
libselinux.so.1 => /lib32/libselinux.so.1 (0xf722d000)
libXdmcp.so.6 => /usr/lib32/libXdmcp.so.6 (0xf7228000)

So far so god... It runs on my system because I have installed 32bit libs but i want to test if it runs on a 32bit environment. If there are any volunteers to test it, we may make a step forward and setup also 32bit build. Here is the test application.
(Feedback expected Wink )
Re: Working on new release system... [message #22330 is a reply to message #20365] Fri, 03 July 2009 23:57 Go to previous messageGo to next message
amrein is currently offline  amrein
Messages: 278
Registered: August 2008
Location: France
Experienced Member
I understand people wanting to play with chrooted distro because it's a cool Linux behaviour. I did it too a few mouths ago. But at the end, for me, Virtual Machine is really the way to go.

Faster to do, easier to manage, smaller to produce, easy to add new build target and you keep total control. Windows, Linux, BSD, whatever, 32 bit, 64 bit, Intel/AMD, ARM and PPC. What could be better?
Re: Working on new release system... [message #22331 is a reply to message #22330] Sat, 04 July 2009 00:38 Go to previous messageGo to next message
andrei_natanael is currently offline  andrei_natanael
Messages: 262
Registered: January 2009
Experienced Member
amrein wrote on Sat, 04 July 2009 00:57

I understand people wanting to play with chrooted distro because it's a cool Linux behaviour. I did it too a few mouths ago. But at the end, for me, Virtual Machine is really the way to go.

Faster to do, easier to manage, smaller to produce, easy to add new build target and you keep total control. Windows, Linux, BSD, whatever, 32 bit, 64 bit, Intel/AMD, ARM and PPC. What could be better?

Well, i know it's simple to use a VM but it use more memory than a chroot system and with less memory the compilation take more, Anyway i think Mirek want to build 32bit directly in 64bit environment without chroot.
Re: Working on new release system... [message #22356 is a reply to message #22331] Tue, 07 July 2009 19:58 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14290
Registered: November 2005
Ultimate Member
andrei_natanael wrote on Fri, 03 July 2009 18:38

amrein wrote on Sat, 04 July 2009 00:57

I understand people wanting to play with chrooted distro because it's a cool Linux behaviour. I did it too a few mouths ago. But at the end, for me, Virtual Machine is really the way to go.

Faster to do, easier to manage, smaller to produce, easy to add new build target and you keep total control. Windows, Linux, BSD, whatever, 32 bit, 64 bit, Intel/AMD, ARM and PPC. What could be better?

Well, i know it's simple to use a VM but it use more memory than a chroot system and with less memory the compilation take more, Anyway i think Mirek want to build 32bit directly in 64bit environment without chroot.


Well, right now I have to say I am quite happy with 'src' to cover POSIX systems.

VMs are fine, I am only afraid about managing all these VMs.

Another consideration is that googlecode space is limited (to 2GB of uploads). Maybe we really need distro flavors only to be uploaded to sf.net.

Mirek
Re: Working on new release system... [message #22357 is a reply to message #22253] Tue, 07 July 2009 20:01 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14290
Registered: November 2005
Ultimate Member
amrein wrote on Sat, 27 June 2009 17:51

For rpm automatic release, we need a script to generate standard Makefile without theide.

Ultimate++ still doesn't have a great command line configure/build system like cmake, automake/autoconf, ant or qmake/tmake. I understood that you didn't want extra dependencies.



I guess we are sort of past this point. Universal POSIX 'src' release is created each night. And it seems to work across platforms just fine.

Mirek

P.S.: Welcome back Smile
Re: Working on new release system... [message #22475 is a reply to message #20365] Sat, 18 July 2009 01:06 Go to previous messageGo to next message
amrein is currently offline  amrein
Messages: 278
Registered: August 2008
Location: France
Experienced Member
Hi luzr Smile

I'm working on 'upp.spec' to be able to build rpm.


What I've found:

- I can't use the default Makefile in root directory because it's for locale build only. Does things like copying theide into ~/ . So I use uppsrc/Makefile instead.

- I can't use the default uppsrc/Makefile without modifying a few variables (LIBPATH, CINC, ...) because of different 64 bit library paths and different include directory paths between Linux distributions. I fixed in the spec file using distribution default paths (I use pkg-config). No problemo.

- I can't automatically add svn version into the rpm spec file (svn can't do that as cvs could) and I don't know when a new release will be out. So to build the rpm you need to submit the package version number and current date like this:

# rpmbuild -tb --define 'version 1314' --define "date $(LC_TIME=En date '+%a %b %d %Y')" upp-x11-src-1314.tar.gz

(Note: this is an example. This won't work at present because upp-x11-src-1314.tar.gz doesn't include the new spec file)


I have just two issues remaining before committing:

1. No default icon for U++ ide. Can't find theide-48.png anymore in svn nor in upp-x11-src-1314.tar.gz.

2. Bad png name in theide.desktop since 2008.1. Should be theide and not theide.png. Here is the patch:


$ cat SOURCES/upp-src-2008.1.fix_png_name_in_desktop_file
diff -p -up ./uppsrc/ide/theide.desktop.fix_png_name_in_desktop_file ./uppsrc/ide/theide.desktop
--- ./uppsrc/ide/theide.desktop.fix_png_name_in_desktop_file 2008-07-28 23:02:06.000000000 +0200
+++ ./uppsrc/ide/theide.desktop 2008-08-17 19:26:10.000000000 +0200
@@ -5,7 +5,7 @@ GenericName=TheIDE
Comment=IDE for cross-platform C++ development
MimeType=application/x-upp
Exec=theide
-Icon=theide.png
+Icon=theide
Terminal=false
Type=Application
Categories=Application;Development;C++


Regards
Re: Working on new release system... [message #22477 is a reply to message #22475] Sat, 18 July 2009 02:55 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14290
Registered: November 2005
Ultimate Member
amrein wrote on Fri, 17 July 2009 19:06

Hi luzr Smile

I'm working on 'upp.spec' to be able to build rpm.


What I've found:

- I can't use the default Makefile in root directory because it's for locale build only. Does things like copying theide into ~/ . So I use uppsrc/Makefile instead.



Well, the default Makefile is for manual building only. That part does not change very often, I think using uppsrc/Makefile is the correct there.

Quote:


- I can't use the default uppsrc/Makefile without modifying a few variables (LIBPATH, CINC, ...) because of different 64 bit library paths and different include directory paths between Linux distributions.



I guess the simple solution, already in use, is to put all different path variants in there. Neither compiler or linker complains about missing directories.

So if you have a suggestion about missing path variants, just post them here Smile

Quote:


- I can't automatically add svn version into the rpm spec file (svn can't do that as cvs could) and I don't know when a new release will be out. So to build the rpm you need to submit the package version number and current date like this:



Check svnversion.

Mirek
Re: Working on new release system... [message #22487 is a reply to message #20365] Sat, 18 July 2009 19:40 Go to previous messageGo to next message
amrein is currently offline  amrein
Messages: 278
Registered: August 2008
Location: France
Experienced Member
New version already commited but I still have the two issue.


To answer your question, here is how I build theide in the rpm spec file:

# make -C uppsrc \
-e LIBPATH=$(pkg-config --libs-only-L x11 freetype2 gtk+-2.0 glib-2.0 cairo pango atk) \
-e CINC=" -I. $(pkg-config --cflags x11 freetype2 gtk+-2.0 glib-2.0 cairo pango atk)" \
-e UPPOUT="$PWD/out/" \
-e OutFile="$PWD/out/ide.out"



Here is how I build GCC.bm:

# INCLUDEDIR=$( pkg-config --cflags x11 freetype2 gtk+-2.0 glib-2.0 cairo pango atk | awk ' { gsub ( / /, "" ) ; gsub ( /-I/, ";" ) ; sub ( /;/, "" ) ; print $0 }' )
LIBDIR=$( pkg-config --libs-only-L x11 freetype2 gtk+-2.0 glib-2.0 cairo pango atk | awk ' { gsub ( / /, "" ) ; gsub ( /-I/, ";" ) ; sub ( /;/, "" ) ; print $0 }' )

cat > %{buildroot}/%{_datadir}/%{name}/GCC.bm << EOF
BUILDER = "GCC";
COMPILER = "g++";
DEBUG_INFO = "2";
DEBUG_BLITZ = "1";
DEBUG_LINKMODE = "1";
DEBUG_OPTIONS = "-O0";
DEBUG_FLAGS = "";
RELEASE_BLITZ = "0";
RELEASE_LINKMODE = "1";
RELEASE_OPTIONS = "-O1 -ffunction-sections";
RELEASE_SIZE_OPTIONS = "-Os -finline-limit=20";
RELEASE_FLAGS = "";
DEBUGGER = "gdb";
PATH = "";
INCLUDE = "$INCLUDEDIR";
LIB = "$LIBDIR";
REMOTE_HOST = "";
REMOTE_OS = "";
REMOTE_TRANSFER = "";
REMOTE_MAP = "";
LINKMODE_LOCK = "0";
EOF


I still have those two issues remaining:

1. No default icon for U++ ide. Can't find theide-48.png anymore in svn nor in upp-x11-src-1314.tar.gz.

2. Bad png name in theide.desktop since 2008.1. Should be theide and not theide.png in theide.desktop file.
Re: Working on new release system... [message #22491 is a reply to message #22487] Sun, 19 July 2009 03:37 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14290
Registered: November 2005
Ultimate Member
amrein wrote on Sat, 18 July 2009 13:40


I still have those two issues remaining:

1. No default icon for U++ ide. Can't find theide-48.png anymore in svn nor in upp-x11-src-1314.tar.gz.



IMO we can take it from previous versions. Where should I put it?

Quote:


2. Bad png name in theide.desktop since 2008.1. Should be theide and not theide.png in theide.desktop file.


Not even sure what theide.desktop is :)\

Mirek
Re: Working on new release system... [message #22525 is a reply to message #22491] Wed, 22 July 2009 15:45 Go to previous messageGo to next message
amrein is currently offline  amrein
Messages: 278
Registered: August 2008
Location: France
Experienced Member
luzr wrote on Sun, 19 July 2009 03:37


IMO we can take it from previous versions. Where should I put it?


Previously it was in "uppsrc/ide/theide-48.png" Cool


luzr wrote on Sun, 19 July 2009 03:37

Quote:

2. Bad png name in theide.desktop since 2008.1. Should be theide and not theide.png in theide.desktop file.

Not even sure what theide.desktop is Smile


This file is an application launcher used by Linux desktop environment like Gnome, KDE, XFE, ... ( www.freedesktop.org/wiki/Specifications/desktop-entry-spec ).

It's here: "uppsrc/ide/theide.desktop".

Re: Working on new release system... [message #22602 is a reply to message #20365] Thu, 30 July 2009 09:48 Go to previous messageGo to next message
amrein is currently offline  amrein
Messages: 278
Registered: August 2008
Location: France
Experienced Member
1. I've attached theide-48.png to this message.

2. The desktop file patch, generated with "diff":


$ cat SOURCES/upp-src-2008.1.fix_png_name_in_desktop_file

diff -p -up ./uppsrc/ide/theide.desktop.fix_png_name_in_desktop_file ./uppsrc/ide/theide.desktop
--- ./uppsrc/ide/theide.desktop.fix_png_name_in_desktop_file    2008-07-28 23:02:06.000000000 +0200
+++ ./uppsrc/ide/theide.desktop 2008-08-17 19:26:10.000000000 +0200
@@ -5,7 +5,7 @@ GenericName=TheIDE
 Comment=IDE for cross-platform C++ development
 MimeType=application/x-upp
 Exec=theide
-Icon=theide.png
+Icon=theide
 Terminal=false
 Type=Application
 Categories=Application;Development;C++
Re: Working on new release system... [message #22623 is a reply to message #22602] Sat, 01 August 2009 12:36 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14290
Registered: November 2005
Ultimate Member
amrein wrote on Thu, 30 July 2009 03:48

1. I've attached theide-48.png to this message.

2. The desktop file patch, generated with "diff":


$ cat SOURCES/upp-src-2008.1.fix_png_name_in_desktop_file

diff -p -up ./uppsrc/ide/theide.desktop.fix_png_name_in_desktop_file ./uppsrc/ide/theide.desktop
--- ./uppsrc/ide/theide.desktop.fix_png_name_in_desktop_file    2008-07-28 23:02:06.000000000 +0200
+++ ./uppsrc/ide/theide.desktop 2008-08-17 19:26:10.000000000 +0200
@@ -5,7 +5,7 @@ GenericName=TheIDE
 Comment=IDE for cross-platform C++ development
 MimeType=application/x-upp
 Exec=theide
-Icon=theide.png
+Icon=theide
 Terminal=false
 Type=Application
 Categories=Application;Development;C++



Thank you, applied.

One thing is not clear to me yet:

Was you able to compile upp-*-src.tar.gz without changes? (just using make / make install)?

Mirek
Re: Working on new release system... [message #22630 is a reply to message #20365] Sat, 01 August 2009 20:04 Go to previous messageGo to next message
amrein is currently offline  amrein
Messages: 278
Registered: August 2008
Location: France
Experienced Member
Quote:

One thing is not clear to me yet:

Was you able to compile upp-*-src.tar.gz without changes? (just using make / make install)?

Mirek


Compiled without changes, yes.

- I used make + custom parameters to compile (see previous post).
- I didn't use 'make install' because the script doesn't copy U++ files where it should. I do this part directly in the rpm '.spec' file.
- I create my own GCC.bm file (as show in previous post, using rpmbuild macro).


This works with upp-x11-src-1438.tar.gz and with previous releases.

But upp-x11-src-1438.tar.gz and other don't have the spec file included so this file is external.

If you want to create automatic rpm build, it will be a pleasure to help out.
Re: Working on new release system... [message #22766 is a reply to message #20365] Wed, 12 August 2009 10:31 Go to previous messageGo to next message
amrein is currently offline  amrein
Messages: 278
Registered: August 2008
Location: France
Experienced Member
Will there be an automatic rpm build system for each new release or do you want me to upload my rpms on sourceforge?
Re: Working on new release system... [message #22767 is a reply to message #22766] Wed, 12 August 2009 10:36 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14290
Registered: November 2005
Ultimate Member
amrein wrote on Wed, 12 August 2009 04:31

Will there be an automatic rpm build system for each new release or do you want me to upload my rpms on sourceforge?


Right now, we have stepped back in this:

Nightly builds are -src and -win32 only. Announced releases should come each 14 days (+/-), koldo will copy nightly build to sf.net and based on it, release maintainers will create platform specific packages and individualy upload to sf.net.

So, the sort answer is: YES. But wait for sources to appear on sf.net (as signal that we called some particular svn revision a "release").

Mirek

[Updated on: Wed, 12 August 2009 10:37]

Report message to a moderator

Re: Working on new release system... [message #23215 is a reply to message #22767] Tue, 29 September 2009 13:55 Go to previous messageGo to next message
amrein is currently offline  amrein
Messages: 278
Registered: August 2008
Location: France
Experienced Member
Could you include trunk/linux_scripts/rpm/upp.spec in next official release? I need it to be able to build rpm packages.
Re: Working on new release system... [message #23283 is a reply to message #23215] Wed, 07 October 2009 11:14 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14290
Registered: November 2005
Ultimate Member
amrein wrote on Tue, 29 September 2009 07:55

Could you include trunk/linux_scripts/rpm/upp.spec in next official release? I need it to be able to build rpm packages.


Official release? Why? How?

Mirek
Re: Working on new release system... [message #23328 is a reply to message #20365] Sat, 10 October 2009 15:26 Go to previous messageGo to next message
amrein is currently offline  amrein
Messages: 278
Registered: August 2008
Location: France
Experienced Member
Quote:

Official release?


upp-x11-src-1517.tar.gz, upp-x11-src-1607.tar.gz, ...

Quote:

How?


upp.spec can be anywhere in the tar.gz directories. The rpmbuild tool will find it anywhere.

Quote:

Why?


Any rpm based distribution will know how to build binary packages (x86, x64, src.rpm, ...) from the tar.gz and It will be easier for me to build packages with my already configured virtual machines.
Re: Working on new release system... [message #23331 is a reply to message #23328] Sun, 11 October 2009 10:02 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14290
Registered: November 2005
Ultimate Member
amrein wrote on Sat, 10 October 2009 09:26

Quote:

Official release?


upp-x11-src-1517.tar.gz, upp-x11-src-1607.tar.gz, ...

Quote:

How?


upp.spec can be anywhere in the tar.gz directories. The rpmbuild tool will find it anywhere.

Quote:

Why?


Any rpm based distribution will know how to build binary packages (x86, x64, src.rpm, ...) from the tar.gz and It will be easier for me to build packages with my already configured virtual machines.


I see, OK, that is reasonable (and interesting).

Hopefully done, check the next nightly build.

In the process, I have moved upp.spec file to uppbox/Scripts (so that it can be edited in Scripts package).

Mirek

Re: Working on new release system... [message #23421 is a reply to message #20365] Sun, 18 October 2009 17:00 Go to previous messageGo to previous message
amrein is currently offline  amrein
Messages: 278
Registered: August 2008
Location: France
Experienced Member
I don't have write access to the repository so here is a patch:


Index: trunk/uppsrc/ide/theide.desktop
===================================================================
--- trunk/uppsrc/ide/theide.desktop     (révision 1634)
+++ trunk/uppsrc/ide/theide.desktop     (copie de travail)
@@ -8,5 +8,5 @@
 Icon=theide
 Terminal=false
 Type=Application
-Categories=Application;Development;C++
+Categories=Application;Development;IDE;C++;
 StartupNotify=false
Index: trunk/uppbox/Scripts/upp.spec
===================================================================
--- trunk/uppbox/Scripts/upp.spec       (révision 1634)
+++ trunk/uppbox/Scripts/upp.spec       (copie de travail)
@@ -90,12 +90,14 @@
 install -d %{buildroot}/%{_bindir}
 install -d %{buildroot}/%{_desktopdir}
 install -d %{buildroot}/%{_datadir}/icons/hicolor/48x48/apps
+install -d %{buildroot}/%{_datadir}/pixmaps
 install -d %{buildroot}/%{_datadir}/%{name}

 install out/ide.out %{buildroot}/%{_bindir}/theide

 cp -p uppsrc/ide/theide.desktop %{buildroot}/%{_desktopdir}/theide.desktop
 cp -p uppsrc/ide/theide-48.png %{buildroot}/%{_datadir}/icons/hicolor/48x48/apps/theide.png
+cp -p uppsrc/ide/theide-48.png %{buildroot}/%{_datadir}/pixmaps/theide.png

 cp -a bazaar %{buildroot}/%{_datadir}/%{name}/
 # cp -a Common %{buildroot}/%{_datadir}/%{name}/
@@ -147,6 +149,7 @@
 %{_bindir}/theide
 %{_desktopdir}/theide.desktop
 %{_datadir}/icons/hicolor/48x48/apps/theide.png
+%{_datadir}/pixmaps/theide.png
 %dir %{_datadir}/%{name}
 %{_datadir}/%{name}/*

Previous Topic: Regular releases reactivated
Next Topic: Releasing deb package issue
Goto Forum:
  


Current Time: Sun Apr 26 16:14:08 GMT+2 2026

Total time taken to generate the page: 0.01480 seconds