Re: Moving gettex.[Ch] and messages.[Ch] to src/support/
Quoting Jean-Marc Lasgouttes <[EMAIL PROTECTED]>: > > "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes: > > Abdelrazak> I guess that would be a "no" from JMarc and Lars so let's > Abdelrazak> just forget about this thread. Sorry for the noise. > > Hey! You did not give me a chance to say "no" by myself! > > So, as far as you original plan is concerned, my answer is indeed "no" > :) That's clear enough :-) > What I propose, though, is that you look at the convenience functions > defined in support/lyxlib.h and see which ones can be replaced by > boost thing. We probably do not need to implement mkdir, for example. > > One way of lessening the portability problem is to delegate it to > boost. Year there is a lot we can do there; but the major burden is actually gettext support. Unless we clean that or separate that from the rest, the configure step will remain slow. Abdel.
[O-T] Re: Moving gettex.[Ch] and messages.[Ch] to src/support/
On Sat, 6 May 2006, Georg Baum wrote: > I am historic? Not at all (or you will be historic in next year, too). While doing my PhD, I think it was my professor who said that you become an export on a (minor) topic in six months. So becoming historic in a year sounds about right to me :-) /C -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: Moving gettex.[Ch] and messages.[Ch] to src/support/
On Mon, May 08, 2006 at 10:30:06AM +0200, Joost Verburg wrote: > Abdelrazak Younes wrote: > > It is already generating it my friend. I was trying to improve the > > present build system which is close to sxxxt as far as I am concerned > > with windows. You say you are caring about portability across old Unix > > and other exotic system but I reckon there are *much* more users on > > windows than the sum of all those other system. It's not that I like > > Windows (far from it) but I am _forced_ to it, so are many others. > > I also think that the development of a scons system is a good thing that > should be supported. The Windows auto* stuff only works on Cygwin and > supports nothing else than GCC. This is not true. They are indeed geared towards gcc but can be made to work with other compilers. Sadly, there are not much of them in the free software domain. > A good scons system will make it possible to compile using MinGW, > Microsoft C++, Borland or whatever using the same scripts. While I have no problems with auto tools, I think that it is wrong to put one's head in the sand. So if something better is proven to exist, it is foolish ignoring it (you would risk to be a dinosaur doomed to extinction). However, I am afraid that this is neither mine nor your call... -- Enrico
Re: Moving gettex.[Ch] and messages.[Ch] to src/support/
Joost Verburg wrote: > A good scons system will make it possible to compile using MinGW, > Microsoft C++, Borland or whatever using the same scripts. > > Joost I'm not a developper and incapable of having a real technical opinion. But why not wait until KDE finishes its transition to CMake. I guess it will take another 6 months to have a working building system on Linux, BSD Mac OSX and Windows and different flavors of compilers, documentation. There is also an evolving ruby script to convert autotools files to CMake in KDE svn. I imagine than in siwx months, LyX will have a better visibility to choose between scons and CMake. The 'dashboard' is also a nice feature for monitoring cross-platform http://public.kitware.com/dashboard.php?name=kde Cheers, Charles -- http://www.kde-france.org
Re: Moving gettex.[Ch] and messages.[Ch] to src/support/
Abdelrazak Younes wrote: It is already generating it my friend. I was trying to improve the present build system which is close to sxxxt as far as I am concerned with windows. You say you are caring about portability across old Unix and other exotic system but I reckon there are *much* more users on windows than the sum of all those other system. It's not that I like Windows (far from it) but I am _forced_ to it, so are many others. I also think that the development of a scons system is a good thing that should be supported. The Windows auto* stuff only works on Cygwin and supports nothing else than GCC. A good scons system will make it possible to compile using MinGW, Microsoft C++, Borland or whatever using the same scripts. Joost
Re: Moving gettex.[Ch] and messages.[Ch] to src/support/
Lars Gullik Bjønnes a écrit : Abdelrazak Younes <[EMAIL PROTECTED]> writes: | First thanks to JMarc and Georg for a great Friday :-) | | Angus rightfully warned me that I will face great resistance here wrt | to autotools. I believe it is more inertia than a religious issue. | People are just afraid of potential bad thing that could happen if we | touch the build system. | | I would like to propose a simpler way forward. | 1) move non lyx core source code that depend on "config.h" defined | macro to "src/support/": mainly gettex.[Ch] and messages.[Ch] Can you please forget this obsession with the file. As long as we use autotools it stays in _all_ source files. For once, could you please read the whole discussion before putting some disease in my mind. This is the fifth time I am acknowledging that config.h is here to stay (that makes twice to you). I was _trying_ to get you understand that most of the macro defined there are support oriented and two config.h (one for support and one for the rest) would make sense. And I don't care one iota that your precious scons does not generate it. It is already generating it my friend. I was trying to improve the present build system which is close to sxxxt as far as I am concerned with windows. You say you are caring about portability across old Unix and other exotic system but I reckon there are *much* more users on windows than the sum of all those other system. It's not that I like Windows (far from it) but I am _forced_ to it, so are many others. | It is not friday so no need to argue for days. A simple yes or no from | main historic devels should be enough. Lars: No blanket permission to do anything, one thing at a time, clear and well thought out. | I could begin to move gettex.[Ch] and messages.[Ch] to "src/support/"; | would a patch like that will be accepted? Not really part of a support lib, it is support yes, but not independant supprt... perhaps. I don't care anymore about autotools and source tree, I will try to help improve scons support which I am sure will help me improving my workflow whithout having to cleanup config.h and the source tree first. Abdel.
Re: Moving gettex.[Ch] and messages.[Ch] to src/support/
Abdelrazak Younes <[EMAIL PROTECTED]> writes: | Georg Baum a écrit : | > Am Samstag, 6. Mai 2006 11:39 schrieb Abdelrazak Younes: | >> First thanks to JMarc and Georg for a great Friday :-) | >> | >> Angus rightfully warned me that I will face great resistance here | >> wrt to autotools. I believe it is more inertia than a religious | >> issue. People are just afraid of potential bad thing that could | >> happen if we touch the build system. | > I don't fear that bad things could happen to the build system. I | > think that a scons-based build system could work quite well for you | > and me and other people with "mainstream" systems and enough | > knowledge about library dependencies etc. who don't rely on binary | > packages. | > I still fear that you don't know how much the auto stuff does for | > us, and that such a new build system would break LyX for some more | > exotic configurations, and that it will ve a lot of work to create | > it (but I am beginning to repeat myself, so I'll stop now). | | Yes and I still think you are overestimating what is in config.h as | proven in my analysis. So that's a "no" for you. Not all that the autotools do are in config.h -- Lgb
Re: Moving gettex.[Ch] and messages.[Ch] to src/support/
Abdelrazak Younes <[EMAIL PROTECTED]> writes: | First thanks to JMarc and Georg for a great Friday :-) | | Angus rightfully warned me that I will face great resistance here wrt | to autotools. I believe it is more inertia than a religious issue. | People are just afraid of potential bad thing that could happen if we | touch the build system. | | I would like to propose a simpler way forward. | 1) move non lyx core source code that depend on "config.h" defined | macro to "src/support/": mainly gettex.[Ch] and messages.[Ch] Can you please forget this obsession with the file. As long as we use autotools it stays in _all_ source files. And I don't care one iota that your precious scons does not generate it. | It is not friday so no need to argue for days. A simple yes or no from | main historic devels should be enough. Lars: No blanket permission to do anything, one thing at a time, clear and well thought out. | I could begin to move gettex.[Ch] and messages.[Ch] to "src/support/"; | would a patch like that will be accepted? Not really part of a support lib, it is support yes, but not independant supprt... perhaps. (especially messages.C) -- Lgb
Re: Moving gettex.[Ch] and messages.[Ch] to src/support/
Angus Leeming a écrit : Abdelrazak Younes wrote: Well, I've lost some battles in LyX development already. The problem is that most of the changes I envision would need full support of maintainers so I loose. My available time is not much so I can't afford to spend time on things that will not be accepted. I have the presumptuousness to think my ideas are interesting so I offer them to the list just in case. At least I hope this could make an interesting reading to wannabe developers :-) I don't think you lose often. Incidentally, I can't see why you're giving up on moving gettext.[Ch] to support. It's clearly the right thing to do. I can't remember clearly what's in messages.[Ch] but I imagine you're correct here too. That's a classical suggestion tactic ;-). I advocate a big shift so that at least a small one could happen. I think that the discussion got side tracked by your stated desire to publish libsupport separately from LyX. One thing at a time! I reckon I am not very good at that... Off to Seattle now. Input from me will be at best displaced by 10 hours and at worst none existent for the next two weeks. (For some definition of best and worst). Have a nice trip there! Abdel.
Re: Moving gettex.[Ch] and messages.[Ch] to src/support/
Abdelrazak Younes wrote: > Well, I've lost some battles in LyX development already. The problem is > that most of the changes I envision would need full support of > maintainers so I loose. My available time is not much so I can't afford > to spend time on things that will not be accepted. I have the > presumptuousness to think my ideas are interesting so I offer them to > the list just in case. At least I hope this could make an interesting > reading to wannabe developers :-) I don't think you lose often. Incidentally, I can't see why you're giving up on moving gettext.[Ch] to support. It's clearly the right thing to do. I can't remember clearly what's in messages.[Ch] but I imagine you're correct here too. I think that the discussion got side tracked by your stated desire to publish libsupport separately from LyX. One thing at a time! Off to Seattle now. Input from me will be at best displaced by 10 hours and at worst none existent for the next two weeks. (For some definition of best and worst). -- Angus
Re: Moving gettex.[Ch] and messages.[Ch] to src/support/
Jose' Matos a écrit : On Saturday 06 May 2006 14:54, Abdelrazak Younes wrote: I guess that would be a "no" from JMarc and Lars so let's just forget about this thread. Sorry for the noise. [wise word from an old man] Moral of the story: If you believe in something fight for it and choose your battles, it is impossible to win everytime. :-) Well, I've lost some battles in LyX development already. The problem is that most of the changes I envision would need full support of maintainers so I loose. My available time is not much so I can't afford to spend time on things that will not be accepted. I have the presumptuousness to think my ideas are interesting so I offer them to the list just in case. At least I hope this could make an interesting reading to wannabe developers :-) Thanks Jose, Abdel.
Re: Moving gettex.[Ch] and messages.[Ch] to src/support/
On Saturday 06 May 2006 14:54, Abdelrazak Younes wrote: > I guess that would be a "no" from JMarc and Lars so let's just forget > about this thread. Sorry for the noise. Since it looks that as I am getting old I am getting a bit wiser let me tell an history of persistence and success (I hope). I always liked python, I still do, if I have to choose between C++ and python I will choose python without any second guess. Depending on the type of problems, notice that I have programs running for months (scientific computing), I may need to use C++ and I like it and use it, but clearly it is not my first choice. I have studied the ancient code in the "lyx archaelogy saga" if you remember. It is an interesting reading no less, and a huge mess, believe me. One of parts where I took personal interest was the file format code, it was more messier that you could ever imagine, a kludge after another to make the code load ancient versions. The situation was becoming impossible to maintain, with lyx only expecting to maintain code compatibility with the two previous versions. A disaster in disguise by other words. I always laugh at the message that lyx had for really old files, "Please install lyx 0.10 to read those files". In 2001/2002 I suggested the best solution was to move that code externally. And clearly I thought that best candidate for the job was a python script. Fortunately and at the same time, Dekel Tsur had some python scripts to convert some old files to new files. I took the general tools from it and generalized the idea. The problem of lyx2lyx was the additional dependence on another external package, python. Yet lyx2lyx proved to be able to refine the lyx file format, after all we had more file format changes during 1.3 than before 1.3 (all together). Notice that most of the convertions were done by Georg and Jürgen with some other by Martin and Angus. And the merit goes to them. :-) The addition of lyx2lyx even allowed to do back-compatibility something impossible before, notice that this is something that I don't care at all. lyx2lyx allowed indirectly the presence of configure.py since python is no longer an external dependence. If I had some time (impossible in the next couple of months) I intend to improve lyx2lyx even further. And FWIW my next target is tex2lyx, I intend to convert it to python to integrate it with LyX python module. Moral of the story: If you believe in something fight for it and choose your battles, it is impossible to win everytime. :-) > Abdel. Unless a change is well thought it will bite you (us) when and where you least expect. I learned to hear them, they are a smart bunch and if they object usually there is a strong reason. If there is not and you prove them that they will admit. Either way we all win. :-) PS: I am tired and this seems like rubbish then ignore it, please. :-) -- José Abílio
Re: Moving gettex.[Ch] and messages.[Ch] to src/support/
Juergen Spitzmueller a écrit : Abdelrazak Younes wrote: It is not friday so no need to argue for days. A simple yes or no from main historic devels should be enough. Lars: JMarc: Georg: Martin: Juergen: I don't think you mean Jürgen Vigna, who is a real historic devel, contrary to me. For my part, I'd leave the decision to those who are really familiar with the build stuff. Yeas, I meant you, Juergen Spitzmueller. By historic I meant those present in the list when I joined in. I guess that would be a "no" from JMarc and Lars so let's just forget about this thread. Sorry for the noise. Abdel.
Re: Moving gettex.[Ch] and messages.[Ch] to src/support/
Abdelrazak Younes wrote: > It is not friday so no need to argue for days. A simple yes or no from > main historic devels should be enough. > Lars: > JMarc: > Georg: > Martin: > Juergen: I don't think you mean Jürgen Vigna, who is a real historic devel, contrary to me. For my part, I'd leave the decision to those who are really familiar with the build stuff. Jürgen
Re: Moving gettex.[Ch] and messages.[Ch] to src/support/
Michael Gerz a écrit : However: If you touch the auto* stuff beware that this will delay 1.5.0 for months with little benefit for the end user!!! 1.5.0 is not going to happen soon anyway Michael. Abdel, if I remember correctly, you want to release 1.5.0 rather sooner than later because of qt4, outline mode, other new features, and general polishing. In addition, I want to have a useable change tracking feature as soon as possible. I suggest keeping the auto* stuff in mind but let's concentrate on the short-term goals first. You're probably right, I'll concentrate on Qt4. Abdel.
Re: Moving gettex.[Ch] and messages.[Ch] to src/support/
Georg Baum a écrit : Am Samstag, 6. Mai 2006 11:39 schrieb Abdelrazak Younes: First thanks to JMarc and Georg for a great Friday :-) Angus rightfully warned me that I will face great resistance here wrt to autotools. I believe it is more inertia than a religious issue. People are just afraid of potential bad thing that could happen if we touch the build system. I don't fear that bad things could happen to the build system. I think that a scons-based build system could work quite well for you and me and other people with "mainstream" systems and enough knowledge about library dependencies etc. who don't rely on binary packages. I still fear that you don't know how much the auto stuff does for us, and that such a new build system would break LyX for some more exotic configurations, and that it will ve a lot of work to create it (but I am beginning to repeat myself, so I'll stop now). Yes and I still think you are overestimating what is in config.h as proven in my analysis. So that's a "no" for you. What do you gain by this? You still need auto for the library. Yes. Are you aware of the fact that such a separation (which might have its theoretical benefits) would create lots of additional maintenance work? I don't think so but hey, this is just my opinion, that's why I am asking. If you truly separate it you need to define a public API that can't be changed easily. Right now we can change the API by simply providing new functions or alter existing ones, and that is a real plus. You will still be free to change it during the development phase. Only the stable series will have a stable API. Quite a lot of project opted for the multiple library approach and the lyx tree is mostly ready for this. I could begin to move gettex.[Ch] and messages.[Ch] to "src/support/"; would a patch like that will be accepted? Apart from the fact that I am not going to give the final answer I'd say that moving around this stuff is a waste of time. Angus and Jean-Marc already provided good reasons to retain config.h in every .C file. I don't see any benefit that outweighs this. I have acknowledged this. I am just saying that most of the macro are for support function so it seems logical to me to separate in too build systems as autotools is apparently not very good at creating different config file. Before you begin to move things around you have to get the OK for removing config.h from .C files, and I predict that this is not going to happen. OK, I guess you're right. Forget about all this. No need to further discuss that. Abdel.
Re: Moving gettex.[Ch] and messages.[Ch] to src/support/
Am Samstag, 6. Mai 2006 11:39 schrieb Abdelrazak Younes: > First thanks to JMarc and Georg for a great Friday :-) > > Angus rightfully warned me that I will face great resistance here wrt to > autotools. I believe it is more inertia than a religious issue. People > are just afraid of potential bad thing that could happen if we touch the > build system. I don't fear that bad things could happen to the build system. I think that a scons-based build system could work quite well for you and me and other people with "mainstream" systems and enough knowledge about library dependencies etc. who don't rely on binary packages. I still fear that you don't know how much the auto stuff does for us, and that such a new build system would break LyX for some more exotic configurations, and that it will ve a lot of work to create it (but I am beginning to repeat myself, so I'll stop now). > I would like to propose a simpler way forward. > 1) move non lyx core source code that depend on "config.h" defined macro > to "src/support/": mainly gettex.[Ch] and messages.[Ch] > 2) make src/support/ a real library with its own autotools machinery. > This library could be code liblyxsupport. > 3) simplify the build system of LyX (the executable) to the bare minimum > (ENABLE_ASSERTION, BOOST_*, etc). > > All the tricky portability issues would be handled by > liblyxsupport.[a,so]. Of course this would mean that one needs to build > independently two things instead of one. But I guess this is not a > problem as it could be automated. The obvious advantage (to me at least) > is of course that the LyX exe building system would be very easy to port > to scons, cmake, visual studio, etc... What do you gain by this? You still need auto for the library. > Apart from that, I believe there > are additional advantages with regard to maintenance, binary > distribution, etc. It will also force developers to have clear and > stable API in the support library. Are you aware of the fact that such a separation (which might have its theoretical benefits) would create lots of additional maintenance work? If you truly separate it you need to define a public API that can't be changed easily. Right now we can change the API by simply providing new functions or alter existing ones, and that is a real plus. > It is not friday so no need to argue for days. A simple yes or no from > main historic devels should be enough. > Lars: > JMarc: > Georg: > Martin: > Juergen: > Andre: > Jose: > Angus: > Michael: > > Am I missing somebody? I am historic? Not at all (or you will be historic in next year, too). > I could begin to move gettex.[Ch] and messages.[Ch] to "src/support/"; > would a patch like that will be accepted? Apart from the fact that I am not going to give the final answer I'd say that moving around this stuff is a waste of time. Angus and Jean-Marc already provided good reasons to retain config.h in every .C file. I don't see any benefit that outweighs this. Before you begin to move things around you have to get the OK for removing config.h from .C files, and I predict that this is not going to happen. My config.h is not even regenerated when I run configure again, as long as I do not specify options that really result in changed config.h content. If your config.h is regenerated too often report this as a bug to the auto people, or create a fake config.h for yourself and use a script instead of "make" that copies this one over the auto-created one every time before you compile. Georg
Re: Moving gettex.[Ch] and messages.[Ch] to src/support/
Abdelrazak Younes wrote: I would like to propose a simpler way forward. 1) move non lyx core source code that depend on "config.h" defined macro to "src/support/": mainly gettex.[Ch] and messages.[Ch] 2) make src/support/ a real library with its own autotools machinery. This library could be code liblyxsupport. 3) simplify the build system of LyX (the executable) to the bare minimum (ENABLE_ASSERTION, BOOST_*, etc). It is not friday so no need to argue for days. A simple yes or no from main historic devels should be enough. Michael: I am not one of the core LyX developers and I have no experience with auto* and scons. However: If you touch the auto* stuff beware that this will delay 1.5.0 for months with little benefit for the end user!!! Abdel, if I remember correctly, you want to release 1.5.0 rather sooner than later because of qt4, outline mode, other new features, and general polishing. In addition, I want to have a useable change tracking feature as soon as possible. I suggest keeping the auto* stuff in mind but let's concentrate on the short-term goals first. Regards, Michael
Re: Moving gettex.[Ch] and messages.[Ch] to src/support/
On Sat, May 06, 2006 at 11:39:37AM +0200, Abdelrazak Younes wrote: > First thanks to JMarc and Georg for a great Friday :-) > > Angus rightfully warned me that I will face great resistance here wrt to > autotools. I believe it is more inertia than a religious issue. People > are just afraid of potential bad thing that could happen if we touch the > build system. I am one of those. > I would like to propose a simpler way forward. > 1) move non lyx core source code that depend on "config.h" defined macro > to "src/support/": mainly gettex.[Ch] and messages.[Ch] > 2) make src/support/ a real library with its own autotools machinery. > This library could be code liblyxsupport. > 3) simplify the build system of LyX (the executable) to the bare minimum > (ENABLE_ASSERTION, BOOST_*, etc). > > All the tricky portability issues would be handled by > liblyxsupport.[a,so]. Of course this would mean that one needs to build > independently two things instead of one. But I guess this is not a > problem as it could be automated. The obvious advantage (to me at least) > is of course that the LyX exe building system would be very easy to port > to scons, cmake, visual studio, etc... Apart from that, I believe there > are additional advantages with regard to maintenance, binary > distribution, etc. It will also force developers to have clear and > stable API in the support library. > > It is not friday so no need to argue for days. A simple yes or no from > main historic devels should be enough. > Lars: > JMarc: > Georg: > Martin: Show us that 1) the concept works, i.e., it really makes things simpler and leads to less recompilation 2) it doesn't break any rarely tested exotic platform builds. > Juergen: > Andre: > Jose: > Angus: > Michael: > > Am I missing somebody? > > I could begin to move gettex.[Ch] and messages.[Ch] to "src/support/"; > would a patch like that will be accepted? That seems relatively risk-free... but shouldn't we have 1.4.2 out before doing big things with the source tree? - Martin pgp95wx4g814w.pgp Description: PGP signature
