Re: build system alternatives (Was: Using vala in GNOME)
On Tue, Jul 1, 2008 at 2:32 AM, Gustavo J. A. M. Carneiro [EMAIL PROTECTED] wrote: On Mon, 2008-06-30 at 23:45 +0300, natan yellin wrote: On Mon, Jun 30, 2008 at 9:59 PM, Mikkel Kamstrup Erlandsen [EMAIL PROTECTED] wrote: 2008/6/30 Gustavo J. A. M. Carneiro [EMAIL PROTECTED]: On Mon, 2008-06-30 at 12:01 -0300, Johan Dahlin wrote: Gustavo J. A. M. Carneiro wrote: On Mon, 2008-06-30 at 15:07 +0100, Alberto Ruiz wrote: [..] Plus, CMake is getting more mature and stable and it already supports VisualStudio and XCode project files conversion, lack of proper extensibility being its only downside at the moment. Lack of extensibility, and use of another arcane custom made programming language (if we can call it that) for everything. No, CMake is not an answer. It is not significantly better than autotools to justify a switch to it IMHO. CMake *is* considerably better. Xcode/VisualStudio are killer features which alone would make a switch worth it. I disagree that Xcode/VisualStudio are killer features. A powerful programming language and extensibility are way better features IMHO. Does a significant percentage of GNOME developers use any of these IDEs? Without such data you can't assert that those are killer features. For the case of Vala, I don't see how CMake handles it any better than autotools. Can we please start to organize ourselves and try to move forward with switching to another build system? We can't switch to any single build system any more than we can switch to a single DVCS. Or to a single programming language, for that matter! Different developers value different features. Modern developers have to adapt to different environments. I, for example, regularly program in C, C++, and Python. I know how to use cvs, subversion, bazaar, git (poorly), and mercurial. In particular I use subversion, bazaar, and mercurial very regularly, all at the same time, git not so much only because I didn't need to. I can hack plain makefiles, autoconf/automake, waf, and scons. And is this an acceptable barrier of entry to Gnome development? Agreed. While the skills that you mentioned do come with time no matter what, you want to avoid forcing beginner developers to chew more than they can swallow. That is a moot point. A beginner chooses *one* project to hack on, that's all. All he has to know is the programming language and tools of that single project. That is an issue when a developer wants to transition to another module, at which point he is probably no longer a beginner. One key point here is the fact that autotools is totally _not_ beginner friendly. I've been involved in several projects where I had to deal with autotools, and I _still_ can't do a single thing without copying and pasting from another projects' auto* files. If the build system is autotools, your assumption about the beginner mastering the system is wrong. Athe same time, I'd rather use autotools consistently than a mix of different build systems. As difficult as autotools is to deal with, at least it's the official build system, and there are plenty of people you can ask for help. In summary: What we really need to do is pick one system that's beginner friendly and stick with that choice wherever possible. Picking and choosing does not work, and there's no point in switching to an equally confusing system. This is basically the same thing as with programming languages. Do you think everything should be coded in C in order to lower the required skill set of beginner hackers? What about Python, C++, Vala, C#, Perl? We ban modules written in those other languages because they force developers to learn a new programming language? Besides, making life easier beginner contributors, fine, I'm all for it. But that has to be balanced with keeping the mental sanity of the contributors we already have. -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic -- Frank Herbert ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: build system alternatives (Was: Using vala in GNOME)
Gustavo J. A. M. Carneiro wrote: On Mon, 2008-06-30 at 23:45 +0300, natan yellin wrote: On Mon, Jun 30, 2008 at 9:59 PM, Mikkel Kamstrup Erlandsen [EMAIL PROTECTED] wrote: 2008/6/30 Gustavo J. A. M. Carneiro[EMAIL PROTECTED]: On Mon, 2008-06-30 at 12:01 -0300, Johan Dahlin wrote: Gustavo J. A. M. Carneiro wrote: On Mon, 2008-06-30 at 15:07 +0100, Alberto Ruiz wrote: [..] Plus, CMake is getting more mature and stable and it already supports VisualStudio and XCode project files conversion, lack of proper extensibility being its only downside at the moment. Lack of extensibility, and use of another arcane custom made programming language (if we can call it that) for everything. No, CMake is not an answer. It is not significantly better than autotools to justify a switch to it IMHO. CMake *is* considerably better. Xcode/VisualStudio are killer features which alone would make a switch worth it. I disagree that Xcode/VisualStudio are killer features. A powerful programming language and extensibility are way better features IMHO. Does a significant percentage of GNOME developers use any of these IDEs? Without such data you can't assert that those are killer features. For the case of Vala, I don't see how CMake handles it any better than autotools. Can we please start to organize ourselves and try to move forward with switching to another build system? We can't switch to any single build system any more than we can switch to a single DVCS. Or to a single programming language, for that matter! Different developers value different features. Modern developers have to adapt to different environments. I, for example, regularly program in C, C++, and Python. I know how to use cvs, subversion, bazaar, git (poorly), and mercurial. In particular I use subversion, bazaar, and mercurial very regularly, all at the same time, git not so much only because I didn't need to. I can hack plain makefiles, autoconf/automake, waf, and scons. And is this an acceptable barrier of entry to Gnome development? Agreed. While the skills that you mentioned do come with time no matter what, you want to avoid forcing beginner developers to chew more than they can swallow. That is a moot point. A beginner chooses *one* project to hack on, that's all. All he has to know is the programming language and tools of that single project. That is an issue when a developer wants to transition to another module, at which point he is probably no longer a beginner. This is basically the same thing as with programming languages. Do you think everything should be coded in C in order to lower the required skill set of beginner hackers? What about Python, C++, Vala, C#, Perl? We ban modules written in those other languages because they force developers to learn a new programming language? Besides, making life easier beginner contributors, fine, I'm all for it. But that has to be balanced with keeping the mental sanity of the contributors we already have. I dont think the point is that moot. Being one of the beginner developers you refer to, I can say that autotools are really daunting. As is that most of Gnome Modules are written in C. Up to now I tried write some patches, but always capitulated because of some autotools and/ or C weirdness. And honestly I dont see why I have to learn that freaking tools, when there is Scons/ Python which are beginner friendly and which I personally use for my own projects. So my contributions this far were limited to the parts of gnome written in python. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: build system alternatives (Was: Using vala in GNOME)
And honestly I dont see why I have to learn that freaking tools, when there is Scons/ Python which are beginner friendly and which I personally use for my own projects. So my contributions this far were limited to the parts of gnome written in python. There should always be some kind of division for this, as with any learning project you'd have beginner, intermediate and advanced. Perhaps we should consider thinking of the build tools/development environment in this way, rather than thinking there is one thing we can impose on people to solve the issue once and for all. BR, K ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: build system alternatives (Was: Using vala in GNOME)
On Tue, 2008-07-01 at 17:51 +0200, Pavel Rojtberg wrote: Gustavo J. A. M. Carneiro wrote: On Mon, 2008-06-30 at 23:45 +0300, natan yellin wrote: On Mon, Jun 30, 2008 at 9:59 PM, Mikkel Kamstrup Erlandsen [EMAIL PROTECTED] wrote: 2008/6/30 Gustavo J. A. M. Carneiro[EMAIL PROTECTED]: On Mon, 2008-06-30 at 12:01 -0300, Johan Dahlin wrote: Gustavo J. A. M. Carneiro wrote: On Mon, 2008-06-30 at 15:07 +0100, Alberto Ruiz wrote: [..] Plus, CMake is getting more mature and stable and it already supports VisualStudio and XCode project files conversion, lack of proper extensibility being its only downside at the moment. Lack of extensibility, and use of another arcane custom made programming language (if we can call it that) for everything. No, CMake is not an answer. It is not significantly better than autotools to justify a switch to it IMHO. CMake *is* considerably better. Xcode/VisualStudio are killer features which alone would make a switch worth it. I disagree that Xcode/VisualStudio are killer features. A powerful programming language and extensibility are way better features IMHO. Does a significant percentage of GNOME developers use any of these IDEs? Without such data you can't assert that those are killer features. For the case of Vala, I don't see how CMake handles it any better than autotools. Can we please start to organize ourselves and try to move forward with switching to another build system? We can't switch to any single build system any more than we can switch to a single DVCS. Or to a single programming language, for that matter! Different developers value different features. Modern developers have to adapt to different environments. I, for example, regularly program in C, C++, and Python. I know how to use cvs, subversion, bazaar, git (poorly), and mercurial. In particular I use subversion, bazaar, and mercurial very regularly, all at the same time, git not so much only because I didn't need to. I can hack plain makefiles, autoconf/automake, waf, and scons. And is this an acceptable barrier of entry to Gnome development? Agreed. While the skills that you mentioned do come with time no matter what, you want to avoid forcing beginner developers to chew more than they can swallow. That is a moot point. A beginner chooses *one* project to hack on, that's all. All he has to know is the programming language and tools of that single project. That is an issue when a developer wants to transition to another module, at which point he is probably no longer a beginner. This is basically the same thing as with programming languages. Do you think everything should be coded in C in order to lower the required skill set of beginner hackers? What about Python, C++, Vala, C#, Perl? We ban modules written in those other languages because they force developers to learn a new programming language? Besides, making life easier beginner contributors, fine, I'm all for it. But that has to be balanced with keeping the mental sanity of the contributors we already have. I dont think the point is that moot. Being one of the beginner developers you refer to, I can say that autotools are really daunting. As is that most of Gnome Modules are written in C. Up to now I tried write some patches, but always capitulated because of some autotools and/ or C weirdness. And honestly I dont see why I have to learn that freaking tools, when there is Scons/ Python which are beginner friendly and which I personally use for my own projects. So my contributions this far were limited to the parts of gnome written in python. Rereading, this has turned into a rant, but posting in the hope that it will be useful: It often puts me off, as an experienced C developer. When I first started looking at GNOME (and indeed Linux) I was an experienced C developer, having worked on various commercial videogames, finding ways to save a few hundred bytes here and there to get stuff to fit in RAM on the target platform... and I still have trouble with the GNU autotools: I want to spend my brainpower thinking about the problem domain of the program, my users, and my code, not having to deal with a pile of hacks upon hacks for
Re: build system alternatives (Was: Using vala in GNOME)
On Tue, 2008-07-01 at 12:19 -0400, David Malcolm wrote: [...] Rereading, this has turned into a rant, but posting in the hope that it will be useful: It often puts me off, as an experienced C developer. When I first started looking at GNOME (and indeed Linux) I was an experienced C developer, having worked on various commercial videogames, finding ways to save a few hundred bytes here and there to get stuff to fit in RAM on the target platform... and I still have trouble with the GNU autotools: I want to spend my brainpower thinking about the problem domain of the program, my users, and my code, not having to deal with a pile of hacks upon hacks for trying to workaround obsolete platforms with a broken linker (or whatever). The vast majority of the input to this tool is mere configuration data, but we're stuck with a model where it gets run through scripts on top of scripts that generate a program that's run as the developer (how many of you audit the generated scripts for malicious content?) I added WAF support to gnome-python and gnome-python-desktop. Doing my best to improve the situation on my end :) Also, I feel that a supposed cross-platform compatibility solution that fails to integrate with Visual Studio on Windows, and with XCode on OS X is broken by definition (not that I use either of these platforms). OS X uses GCC for all compilation. Wanting the build tool to interact with the OS X IDE is too much to ask for IMHO. And you can run mingw/GCC on win32 too. And Visual Studio has command line tools for compilation, it's not just an IDE. Again, asking for the tool to also generate Visual Studio project files is too much to ask. Command line is enough. Nothing stops you from editing the source files with your favorite IDE, even if the build tool works from the command line. If a developer cannot use the command line, how is he expected to install a GNOME module, to test it? And lets not forget other IDEs. What about Eclipse, shouldn't we add IDE support for it also? Where does it stop? Also, I find it funny that people that do not actually use either XCode or Visual Studio claim that supporting them is crucial. Again, I don't trust that judgement without proof (statistics). Now, I do know a few developers that use Visual Studio and can't live without it. But among GNOME developers I have serious doubts anyone uses one of those IDEs. -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic -- Frank Herbert ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: build system alternatives (Was: Using vala in GNOME)
Gustavo J. A. M. Carneiro wrote: On Tue, 2008-07-01 at 12:19 -0400, David Malcolm wrote: [..] Also, I find it funny that people that do not actually use either XCode or Visual Studio claim that supporting them is crucial. Again, I don't trust that judgement without proof (statistics). Now, I do know a few developers that use Visual Studio and can't live without it. But among GNOME developers I have serious doubts anyone uses one of those IDEs. Exactly because we don't have Visual Studio/XCode integration. But adding them we would increase the developers that would be able to contribute to GNOME significantly. How do you expect Mac/Windows developers to contribute to GNOME if they can't even build it in their environment? These arguments applies to the part of the stack that are usable outside of Linux/X11 which are not all of them. But we are starting to see more and more applications (Gimp, Evolution etc) that are ported to non-X11 platforms. From my point of view, Gtk+ the stack below dominates the platform. What they will use will eventually be propagated up in the upper part of the platform stack. The contribution barrier for GNOME is way to high as it is today, I'm merely trying to reduce it by allowing developers from other (as in non-unix) backgrounds be able to contribute. Johan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: build system alternatives (Was: Using vala in GNOME)
On Tue, 2008-07-01 at 16:02 -0300, Johan Dahlin wrote: The contribution barrier for GNOME is way to high as it is today, I'm merely trying to reduce it by allowing developers from other (as in non-unix) backgrounds be able to contribute. Strategically speaking, while I think it makes sense for GNOME to invest in the fundamentals (core GTK+ windowing, DBus) of running on non-freedesktop.org platforms[1], developer time is better spent pushing the free platform as a whole forward. Competing with Qt/Swing/Windows.Forms/XULRunner/AIR (Qt in particular) for this is a big project. So in this particular case, our target audience for GTK+ on Windows/OS X is experienced developers familiar with the free desktop stack who at least somewhat understand autotools, etc. [1] I tend not to say Linux for this anymore; freedesktop.org is a lot more accurate ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: build system alternatives (Was: Using vala in GNOME)
2008/7/1 Colin Walters [EMAIL PROTECTED]: On Tue, 2008-07-01 at 16:02 -0300, Johan Dahlin wrote: Strategically speaking, while I think it makes sense for GNOME to invest in the fundamentals (core GTK+ windowing, DBus) of running on non-freedesktop.org platforms[1], developer time is better spent pushing the free platform as a whole forward. Competing with Qt/Swing/Windows.Forms/XULRunner/AIR (Qt in particular) for this is a big project. Exactly, and to push it forward we need to build bridges for people to migrate. Thunderbird is the email client of choice in a lot of universities and corporate environments because you learn how to use the tool once and then admins can switch the platform from Windows to Linux to Mac OS X with one less issue to worry about. There's simply no way to provide a non steep migration path for people from Windows or Mac OS X to Linux besides thunderbird+firefox+openoffice.org. GIMP and Inkscape are successful cross platform projects already, but to support those platforms they spend a huge amount of resources on creating build scripts and environments that cannot be easily replicated. Part of them having to spend so much time is our fault. I would like to see Evince being the most popular lightweight PDF reader at Windows, and college students using PyGtk to learn GUI development on their Windows XP workstations on college labs. 99% of the time this situation of lack of support on non-freedesktop platform has nothing to do with our code being not portable rather than the tools we use to build it. This leads to a lack of interest on choosing it to build cross platform tools, and almost no specific contributions to support those platforms properly. So basically, my ultimate goal is to enable freedesktop.org compliant platforms, and the GNOME platform and desktop a bridge to get users and developers where the volume really is at the moment, which is the Windows and up to some extend the Mac environment. This user base is conformed mostly by people that simply don't know that they have a choice (and don't have in some circumstances). Having a powerful set of cross platform tools is a great way to attract users and developers to desktop freedom! ...dude, I really need to learn to summarize my points, I'm writting pretty long and boring emails lately! [1] I tend not to say Linux for this anymore; freedesktop.org is a lot more accurate I actually like that term ;-) -- Cheers, Alberto Ruiz ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: build system alternatives (Was: Using vala in GNOME)
Colin Walters wrote: On Tue, 2008-07-01 at 16:02 -0300, Johan Dahlin wrote: The contribution barrier for GNOME is way to high as it is today, I'm merely trying to reduce it by allowing developers from other (as in non-unix) backgrounds be able to contribute. Strategically speaking, while I think it makes sense for GNOME to invest in the fundamentals (core GTK+ windowing, DBus) of running on non-freedesktop.org platforms[1], developer time is better spent pushing the free platform as a whole forward. Competing with Qt/Swing/Windows.Forms/XULRunner/AIR (Qt in particular) for this is a big project. Great success for me would be to have people chose GTK/GNOME technologies to develop cross-platform applications. I don't really see that as negative impact on the development of the GNOME platform, rather the opposite by helping it to be even more successful by deploying it on more systems. There are two different strategies of pursuing our agenda. Either using completely free systems or having free programs running on what is non-free systems below. Not completely unlike comparing the Top-down or Bottom-up kind of designs. Let's do both, trying all possible ways of making people use our software. So in this particular case, our target audience for GTK+ on Windows/OS X is experienced developers familiar with the free desktop stack who at least somewhat understand autotools, etc. My interest is mainly the GTK+ part of the stack, which should be considerably easier to support. I'm not talking about taking away developer time from already busy developers. Just widening the developer base and allowing more expertize to contribute to the platform. Johan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: build system alternatives (Was: Using vala in GNOME)
On Mon, 2008-06-30 at 12:01 -0300, Johan Dahlin wrote: Gustavo J. A. M. Carneiro wrote: On Mon, 2008-06-30 at 15:07 +0100, Alberto Ruiz wrote: [..] Plus, CMake is getting more mature and stable and it already supports VisualStudio and XCode project files conversion, lack of proper extensibility being its only downside at the moment. Lack of extensibility, and use of another arcane custom made programming language (if we can call it that) for everything. No, CMake is not an answer. It is not significantly better than autotools to justify a switch to it IMHO. CMake *is* considerably better. Xcode/VisualStudio are killer features which alone would make a switch worth it. I disagree that Xcode/VisualStudio are killer features. A powerful programming language and extensibility are way better features IMHO. Does a significant percentage of GNOME developers use any of these IDEs? Without such data you can't assert that those are killer features. For the case of Vala, I don't see how CMake handles it any better than autotools. Can we please start to organize ourselves and try to move forward with switching to another build system? We can't switch to any single build system any more than we can switch to a single DVCS. Or to a single programming language, for that matter! Different developers value different features. Modern developers have to adapt to different environments. I, for example, regularly program in C, C++, and Python. I know how to use cvs, subversion, bazaar, git (poorly), and mercurial. In particular I use subversion, bazaar, and mercurial very regularly, all at the same time, git not so much only because I didn't need to. I can hack plain makefiles, autoconf/automake, waf, and scons. Proposal: - Decide features we need to do a migrate - Create a table of proposed build systems x features - Check the KDE build system migration and see what we can learn[1] - An obvious option will eventually appear - Start migrate some modules [1]: Tim has some notes on this: http://blogs.gnome.org/timj/2008/06/02/02062008-linuxtag-2008/ Johan -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic -- Frank Herbert ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: build system alternatives (Was: Using vala in GNOME)
2008/6/30 Gustavo J. A. M. Carneiro [EMAIL PROTECTED]: On Mon, 2008-06-30 at 12:01 -0300, Johan Dahlin wrote: Gustavo J. A. M. Carneiro wrote: On Mon, 2008-06-30 at 15:07 +0100, Alberto Ruiz wrote: [..] Plus, CMake is getting more mature and stable and it already supports VisualStudio and XCode project files conversion, lack of proper extensibility being its only downside at the moment. Lack of extensibility, and use of another arcane custom made programming language (if we can call it that) for everything. No, CMake is not an answer. It is not significantly better than autotools to justify a switch to it IMHO. CMake *is* considerably better. Xcode/VisualStudio are killer features which alone would make a switch worth it. I disagree that Xcode/VisualStudio are killer features. A powerful programming language and extensibility are way better features IMHO. Does a significant percentage of GNOME developers use any of these IDEs? Without such data you can't assert that those are killer features. For the case of Vala, I don't see how CMake handles it any better than autotools. Can we please start to organize ourselves and try to move forward with switching to another build system? We can't switch to any single build system any more than we can switch to a single DVCS. Or to a single programming language, for that matter! Different developers value different features. Modern developers have to adapt to different environments. I, for example, regularly program in C, C++, and Python. I know how to use cvs, subversion, bazaar, git (poorly), and mercurial. In particular I use subversion, bazaar, and mercurial very regularly, all at the same time, git not so much only because I didn't need to. I can hack plain makefiles, autoconf/automake, waf, and scons. And is this an acceptable barrier of entry to Gnome development? Cheers, Mikkel ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: build system alternatives (Was: Using vala in GNOME)
On Mon, Jun 30, 2008 at 9:59 PM, Mikkel Kamstrup Erlandsen [EMAIL PROTECTED] wrote: 2008/6/30 Gustavo J. A. M. Carneiro [EMAIL PROTECTED]: On Mon, 2008-06-30 at 12:01 -0300, Johan Dahlin wrote: Gustavo J. A. M. Carneiro wrote: On Mon, 2008-06-30 at 15:07 +0100, Alberto Ruiz wrote: [..] Plus, CMake is getting more mature and stable and it already supports VisualStudio and XCode project files conversion, lack of proper extensibility being its only downside at the moment. Lack of extensibility, and use of another arcane custom made programming language (if we can call it that) for everything. No, CMake is not an answer. It is not significantly better than autotools to justify a switch to it IMHO. CMake *is* considerably better. Xcode/VisualStudio are killer features which alone would make a switch worth it. I disagree that Xcode/VisualStudio are killer features. A powerful programming language and extensibility are way better features IMHO. Does a significant percentage of GNOME developers use any of these IDEs? Without such data you can't assert that those are killer features. For the case of Vala, I don't see how CMake handles it any better than autotools. Can we please start to organize ourselves and try to move forward with switching to another build system? We can't switch to any single build system any more than we can switch to a single DVCS. Or to a single programming language, for that matter! Different developers value different features. Modern developers have to adapt to different environments. I, for example, regularly program in C, C++, and Python. I know how to use cvs, subversion, bazaar, git (poorly), and mercurial. In particular I use subversion, bazaar, and mercurial very regularly, all at the same time, git not so much only because I didn't need to. I can hack plain makefiles, autoconf/automake, waf, and scons. And is this an acceptable barrier of entry to Gnome development? Agreed. While the skills that you mentioned do come with time no matter what, you want to avoid forcing beginner developers to chew more than they can swallow. Cheers, Mikkel ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: build system alternatives (Was: Using vala in GNOME)
On Mon, 2008-06-30 at 23:45 +0300, natan yellin wrote: On Mon, Jun 30, 2008 at 9:59 PM, Mikkel Kamstrup Erlandsen [EMAIL PROTECTED] wrote: 2008/6/30 Gustavo J. A. M. Carneiro [EMAIL PROTECTED]: On Mon, 2008-06-30 at 12:01 -0300, Johan Dahlin wrote: Gustavo J. A. M. Carneiro wrote: On Mon, 2008-06-30 at 15:07 +0100, Alberto Ruiz wrote: [..] Plus, CMake is getting more mature and stable and it already supports VisualStudio and XCode project files conversion, lack of proper extensibility being its only downside at the moment. Lack of extensibility, and use of another arcane custom made programming language (if we can call it that) for everything. No, CMake is not an answer. It is not significantly better than autotools to justify a switch to it IMHO. CMake *is* considerably better. Xcode/VisualStudio are killer features which alone would make a switch worth it. I disagree that Xcode/VisualStudio are killer features. A powerful programming language and extensibility are way better features IMHO. Does a significant percentage of GNOME developers use any of these IDEs? Without such data you can't assert that those are killer features. For the case of Vala, I don't see how CMake handles it any better than autotools. Can we please start to organize ourselves and try to move forward with switching to another build system? We can't switch to any single build system any more than we can switch to a single DVCS. Or to a single programming language, for that matter! Different developers value different features. Modern developers have to adapt to different environments. I, for example, regularly program in C, C++, and Python. I know how to use cvs, subversion, bazaar, git (poorly), and mercurial. In particular I use subversion, bazaar, and mercurial very regularly, all at the same time, git not so much only because I didn't need to. I can hack plain makefiles, autoconf/automake, waf, and scons. And is this an acceptable barrier of entry to Gnome development? Agreed. While the skills that you mentioned do come with time no matter what, you want to avoid forcing beginner developers to chew more than they can swallow. That is a moot point. A beginner chooses *one* project to hack on, that's all. All he has to know is the programming language and tools of that single project. That is an issue when a developer wants to transition to another module, at which point he is probably no longer a beginner. This is basically the same thing as with programming languages. Do you think everything should be coded in C in order to lower the required skill set of beginner hackers? What about Python, C++, Vala, C#, Perl? We ban modules written in those other languages because they force developers to learn a new programming language? Besides, making life easier beginner contributors, fine, I'm all for it. But that has to be balanced with keeping the mental sanity of the contributors we already have. -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic -- Frank Herbert ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: build system alternatives (Was: Using vala in GNOME)
2008/7/1 Gustavo J. A. M. Carneiro [EMAIL PROTECTED]: On Mon, 2008-06-30 at 23:45 +0300, natan yellin wrote: On Mon, Jun 30, 2008 at 9:59 PM, Mikkel Kamstrup Erlandsen [EMAIL PROTECTED] wrote: 2008/6/30 Gustavo J. A. M. Carneiro [EMAIL PROTECTED]: On Mon, 2008-06-30 at 12:01 -0300, Johan Dahlin wrote: Gustavo J. A. M. Carneiro wrote: On Mon, 2008-06-30 at 15:07 +0100, Alberto Ruiz wrote: [..] Plus, CMake is getting more mature and stable and it already supports VisualStudio and XCode project files conversion, lack of proper extensibility being its only downside at the moment. Lack of extensibility, and use of another arcane custom made programming language (if we can call it that) for everything. No, CMake is not an answer. It is not significantly better than autotools to justify a switch to it IMHO. CMake *is* considerably better. Xcode/VisualStudio are killer features which alone would make a switch worth it. I disagree that Xcode/VisualStudio are killer features. A powerful programming language and extensibility are way better features IMHO. Does a significant percentage of GNOME developers use any of these IDEs? Without such data you can't assert that those are killer features. For the case of Vala, I don't see how CMake handles it any better than autotools. Can we please start to organize ourselves and try to move forward with switching to another build system? We can't switch to any single build system any more than we can switch to a single DVCS. Or to a single programming language, for that matter! Different developers value different features. Modern developers have to adapt to different environments. I, for example, regularly program in C, C++, and Python. I know how to use cvs, subversion, bazaar, git (poorly), and mercurial. In particular I use subversion, bazaar, and mercurial very regularly, all at the same time, git not so much only because I didn't need to. I can hack plain makefiles, autoconf/automake, waf, and scons. And is this an acceptable barrier of entry to Gnome development? Agreed. While the skills that you mentioned do come with time no matter what, you want to avoid forcing beginner developers to chew more than they can swallow. That is a moot point. A beginner chooses *one* project to hack on, that's all. All he has to know is the programming language and tools of that single project. GNOME is not a collection of desktop modules, is a development environment as well, and consistency within the development process and tool chain is a must for documentation, integration and to avoid effort duplication among tools. I'd rather stick to autotools than having 3 or 4 different build systems within the GNOME module set. In any case, most people don't choose autotools themselves, they choose whatever GNOME want to choose, and whatever people espect to use to build a GNOME module. So yes, one has to be choosen for the 90% of people who don't actually want to choose. That is an issue when a developer wants to transition to another module, at which point he is probably no longer a beginner. This is basically the same thing as with programming languages. Do you think everything should be coded in C in order to lower the required skill set of beginner hackers? It's not only about beginners, but also about duplication of efforts (supporting the same tools within different build systems), ability to check how other maintainers perform a certain operation. There should not be a big issue if a few modules choose their own build system, but select one supported choice that is used for 90% of the cases is going to help people to move forward and spend time on what really matters for us: writing the code that is being built by copy pasting what other projects have done already. -- Cheers, Alberto Ruiz ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
