Home » Developing U++ » Releasing U++ » Welcome and lets finish that 2007.1
|
|
|
|
| Re: Welcome and lets finish that 2007.1 [message #8464 is a reply to message #8461] |
Mon, 12 March 2007 15:19   |
|
|
| Quote: |
I guess we have bad metology for major releases.
I think the *major* release should start with Bas releasing src version (+ linux packages), because Bas can fix the Makefile. Daniel then should download this "src" and prepare Win32 releases based on it to keep consistency.
Other maintainers could add theirs versions later.
|
Well, win32 release is our MAIN release. That's why I'm preparing src file for Bas. Consistency is kept - but in opposite way. We could change it but 1) I don't see a good reason now (what that would change?) 2) Bas and I have our own tools to make packages optimized for proper input - uvs in my tool and zip file in Bas. Changing this would require time and tests.
In my opinion all maintainters should get sources directly from uvs. "Final" release should be tagged and all mainainers should sync those tagged sources. I only don't know if that is possible in current uvs. If not adding it is worth considering.
|
|
|
|
|
|
| Re: Welcome and lets finish that 2007.1 [message #8486 is a reply to message #8464] |
Tue, 13 March 2007 15:00 |
 |
mirek
Messages: 14291
Registered: November 2005
|
Ultimate Member |
|
|
| unodgs wrote on Mon, 12 March 2007 10:19 |
Well, win32 release is our MAIN release. That's why I'm preparing src file for Bas. Consistency is kept - but in opposite way. We could change it but 1) I don't see a good reason now (what that would change?)
|
Let see what happened to all of our rc-s - win32 release was always fine, but there was a problem in Linux. That is why I think releasing Linux version first is such a good idea.
| Quote: |
"Final" release should be tagged and all mainainers should sync those tagged sources.
|
Yes, but rc is that final release. Actually, I agree with you, the simple way is to get sources from uvs. There are no tags, but I think there is not that much uploaders to avoid problems.
OTOH, it sort of reminds me another issue - after finaly releasing, we might need to maintain 2007.1 for a while, fixing critical bugs...
Mirek
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Linux Makefile(s) [message #8630 is a reply to message #8623] |
Thu, 22 March 2007 00:54 |
guido
Messages: 169
Registered: April 2006
|
Experienced Member |
|
|
| luzr wrote on Wed, 21 March 2007 20:31 |
| guido wrote on Tue, 20 March 2007 10:44 |
| luzr wrote on Tue, 20 March 2007 14:44 |
The key person is Bas. The key problem is Linux release.
|
So, what are the remaining issues exactly?
Guido
|
Stupid details... (lower/upper case issues in filenames, the correct selection of uppsrc packages etc...).
But it is coming (finally).
Mirek
|
I just discovered an X11 RichEdit paste bug.
In UWord I can't paste in the RichEdit ctrl within a UWord instance, be it within a document or to another document. But to another UWord instance it works. Only RichEdit to RichEdit exhibits this behaviour, EditString and LineEdit are OK, also RichEdit to EditString etc.
Topic++ has this problem in the exact same way, so there really is a bug in RichEdit clipboard management.
Guido
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Linux Makefile(s) [message #8664 is a reply to message #8663] |
Thu, 22 March 2007 23:48 |
Novo
Messages: 1431
Registered: December 2006
|
Ultimate Contributor |
|
|
Here they are ...
A command line I'm using to generate vc71 project files:
perl D:\bin\MPC\3.4.90\mwc.pl -nocomments -type vc71 -name_modifier *_vc71 -include mpc/config -relative UPP_ROOT=2007.1rc3 2007.1rc3/upp_ws.mwc
The icpp-problem is still not solved.
Regards,
Novo
|
|
|
|
| Re: Linux Makefile(s) [message #8669 is a reply to message #8630] |
Fri, 23 March 2007 11:33 |
|
mirek
Messages: 14291
Registered: November 2005
|
Ultimate Member |
|
|
| guido wrote on Wed, 21 March 2007 19:54 |
| luzr wrote on Wed, 21 March 2007 20:31 |
| guido wrote on Tue, 20 March 2007 10:44 |
| luzr wrote on Tue, 20 March 2007 14:44 |
The key person is Bas. The key problem is Linux release.
|
So, what are the remaining issues exactly?
Guido
|
Stupid details... (lower/upper case issues in filenames, the correct selection of uppsrc packages etc...).
But it is coming (finally).
Mirek
|
I just discovered an X11 RichEdit paste bug.
In UWord I can't paste in the RichEdit ctrl within a UWord instance, be it within a document or to another document. But to another UWord instance it works. Only RichEdit to RichEdit exhibits this behaviour, EditString and LineEdit are OK, also RichEdit to EditString etc.
Topic++ has this problem in the exact same way, so there really is a bug in RichEdit clipboard management.
Guido
|
Fixed.
|
|
|
|
|
|
| Re: Linux Makefile(s) [message #8678 is a reply to message #8674] |
Sat, 24 March 2007 00:44 |
Novo
Messages: 1431
Registered: December 2006
|
Ultimate Contributor |
|
|
| ebojd wrote on Fri, 23 March 2007 11:41 |
I took a quick look last night at MPC. My concern with taking adopting this tools is that it looks like there could be license compatibility problems. It does look like a nice exterior package solution though...
|
From the MPC's License:
"Since MPC is open source and free of licensing fees, you are free to use, modify, and distribute the source code, as long as you include this copyright statement.
In particular, you can use MPC to build proprietary software and are under no obligation to redistribute any of your source code that is built using MPC."
So, no visible restrictions except of a copyright. And you are free to distribute generated files ...
There is a big difference between MPC and jam/bjam. jam is a build system like make. It doesn't generate project files of any kind. It builds everything itself. In opposite, MPC doesn't build anything itself. It generates make/project files. Basically, it is a template engine. Main advantage of MPC over other template engines is that it has quite simple and efficient language to describe everything related to organizing of software packages. I wouldn't say MPC is perfect, but it is usable. And it saves a lot of time. 
| Quote: |
So, is this seriously open for discussion, or just exploring? The likely easiest solution is to add scripting to the package organizer, and then it is just replacing the X11, etc., library directives with pkg-config...
EBo --
|
I've been asked to post a script. 
I needed project files for Visual Studio because of a debugger. So, I've made them and shared with others.
Regards,
Novo
|
|
|
|
|
|
| Re: Linux Makefile(s) [message #8690 is a reply to message #8687] |
Sat, 24 March 2007 18:48 |
|
|
| luzr wrote on Sat, 24 March 2007 12:05 |
* "Glossy theme bug in Ubuntu", Daniel, do you experience it after recompiling? (I do not
|
You were right about the old version of ide. I will check the new one ASAP.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Linux Makefile(s) [message #8759 is a reply to message #8758] |
Thu, 29 March 2007 14:51 |
|
mirek
Messages: 14291
Registered: November 2005
|
Ultimate Member |
|
|
| ebojd wrote on Thu, 29 March 2007 08:31 |
 ummm...  well... 
just trying to be helpful. Hope I did not offend or insult. *that* was not my intent.
BTW, do you keep a single copy of the source in /usr/share/upp (or similar), or do you also have a copy of the source in ~/upp/uppsrc, ~/upp/Common, etc.? It was the latter which cam back to byte me.
EBo --
|
Well, I have sources on FAT32 partition, so that I can use the same files for both Win32 and Linux. On Linux, it is something like /media/sda5/uppsrc...
I almost always use "actual" version of U++ for everything, including my commercial apps.
Mirek
|
|
|
|
|
|
| Re: Linux Makefile(s) [message #8765 is a reply to message #8762] |
Thu, 29 March 2007 17:38 |
|
mirek
Messages: 14291
Registered: November 2005
|
Ultimate Member |
|
|
| ebojd wrote on Thu, 29 March 2007 10:01 |
How do you deal with user side applications which require specific versions of u++ source?
|
Special version of U++? Why?
Well, one thing is perhaps relevant - U++ development was for quite a long time "bussines app driven" - U++ was simply extended to satisfy demands of our customers.
Also, sometimes we refactor interface. Usually, this means fixing all applications, and yes, it is a bit annoying, but that is the price of perfection (and hopefuly, this will not happen too much in future).
BTW, "uppsrc" has more packages than you see in normal release. Many of them are "backward compatibility", some of them experimental or supporting some specific application (or simply not stable and refined enough).
Mirek
|
|
|
|
| Re: Linux Makefile(s) [message #8770 is a reply to message #8765] |
Thu, 29 March 2007 17:53 |
ebojd
Messages: 225
Registered: January 2007
Location: USA
|
Experienced Member |
|
|
| luzr wrote on Thu, 29 March 2007 10:38 |
Special version of U++? Why?
Well, one thing is perhaps relevant - U++ development was for quite a long time "bussines app driven" - U++ was simply extended to satisfy demands of our customers.
Also, sometimes we refactor interface. Usually, this means fixing all applications, and yes, it is a bit annoying, but that is the price of perfection (and hopefuly, this will not happen too much in future).
BTW, "uppsrc" has more packages than you see in normal release. Many of them are "backward compatibility", some of them experimental or supporting some specific application (or simply not stable and refined enough).
Mirek
|
When I ran into the problem of my code compiling libraries from ~/upp/uppsrc/* instead of the new ones in /usr/share/upp/uppsrc/* I got to thinking about why having a seperate copy would be necessary or useful. The most obvious would be for long term application maintenance, by bundling the library code. I had not realized (when I first ran u++) what the implications of having a copy of uppsrc, etc., made to ~/upp/. After thinking about it a little while I realized that library versions could be managed similar to how portage deals with multiple versions of libraries using slots, and they can be compiled against specific revisions of the source...
Hmmm... I just realized that this discussion is in releasing u++ and not in the coffee corner where I intended to keep it. How does one move a discussion to a different forum?
Anyway, thanks for the great work, the discussion, and putting up with my ramblings whilst I learn the system.
EBo --
|
|
|
|
Goto Forum:
Current Time: Tue May 12 19:54:05 GMT+2 2026
Total time taken to generate the page: 0.01033 seconds
|
U++ framework
Search
Help
Members
Register
Login
Home
