directory reorganization
SO I proceeded with the dir. reorg. last night and I have the head compiling and all that. I still have some other little tweaks, but the largest chunk (excluding packaging) has been committed.
Please make sure that I did not break anything. The icons and extensions folders now are inside share. Also, I put the svg files that were in icons (about.svg, keys.svg, and tutorial.svg) and put them into share/screens and updated and created a variable INKSCAPE_SCREENDIR instead of INKSCAPE_PIXMAPDIR for these files where accessed in help.cpp (this is defined in src/Makefile.am).
ISHMAL, could you please look and see how a fresh cvs windows build works. I have a strong feeling that a I broke it, as I have no test box and tried to conceptually follow what I did on the linux side. The part that might not work I'm pretty sure is contained in config.h.mingw and Makefile.mingw I believe. I became slightly confused after staring at weird makefile syntax for a couple of hours.
I will delve further into cleaning up the makefiles now that I understand automake and makefiles much better. There is sooo much legacy architecture and cheap hacks where the same paths are called in different places in the makefiles. Also, would you all agree that I should migrate the current recursive makefiles to just one top-level makefile? You all might also email me/the list a wishlist of how to clean up the source tree and the makefile nasties as they currently exist.
If you want to refer to the dir. reorg plan: http://inkscape.org/cgi-bin/wiki.pl?DirectoryReorgProposal
Thank you,
Jon
On Sun, 2004-02-29 at 03:59, Jonathan Phillips wrote:
I will delve further into cleaning up the makefiles now that I understand automake and makefiles much better. There is sooo much legacy architecture and cheap hacks where the same paths are called in different places in the makefiles. Also, would you all agree that I should migrate the current recursive makefiles to just one top-level makefile? You all might also email me/the list a wishlist of how to clean up the source tree and the makefile nasties as they currently exist.
Uhm, yeah. I like the recursive Makefiles. I like being able to work in one directory (e.g. extension) and being able to continually rebuild that directory to get all the warnings and errors out. Also, by building the individual libraries I think it will be easier to create test programs that work with them (e.g. the ones in libnr). So, while I know there is a lot of cruft in the automake files (which should be removed), I think that recursive Makefiles is a good thing.
--Ted
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Are you taking into account a theme directory for pixmaps etcc? /pixmaps/theme/default /pixmaps/theme/gimpized Yours: Nestor
El Domingo 29 Febrero 2004 17:13, Ted Gould escribió:
On Sun, 2004-02-29 at 03:59, Jonathan Phillips wrote:
I will delve further into cleaning up the makefiles now that I understand automake and makefiles much better. There is sooo much legacy architecture and cheap hacks where the same paths are called in different places in the makefiles. Also, would you all agree that I should migrate the current recursive makefiles to just one top-level makefile? You all might also email me/the list a wishlist of how to clean up the source tree and the makefile nasties as they currently exist.
Uhm, yeah. I like the recursive Makefiles. I like being able to work in one directory (e.g. extension) and being able to continually rebuild that directory to get all the warnings and errors out. Also, by building the individual libraries I think it will be easier to create test programs that work with them (e.g. the ones in libnr). So, while I know there is a lot of cruft in the automake files (which should be removed), I think that recursive Makefiles is a good thing.
--Ted
- -- www.barriolinux.net www.augcyl.org gnuva.hispalinux.es www.hispalinux.es gimp.es.gnome.org
Currently all icons from the program (non gtk-stock) come from share/icons/*.xpm. Are you asking me to implement a system so that based on the theme of the windowmanager, would change Inkscape accordingly and if there is no folder for themes, then use the default icons?
Does anyone have thoughts on this as well? It seems that this would be a lot of extra work and that the app would benefit from having a unified set of icons that *don't* changed just because of a system's theme. Also, I don't know if this is a very high priority compared with other features. My gut feeling is to not implement this, but if you would like to, then go right ahead.
Jon
On Sun, 2004-02-29 at 10:31, Nestor Diaz Valencia wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Are you taking into account a theme directory for pixmaps etcc? /pixmaps/theme/default /pixmaps/theme/gimpized Yours: Nestor
El Domingo 29 Febrero 2004 17:13, Ted Gould escribió:
On Sun, 2004-02-29 at 03:59, Jonathan Phillips wrote:
I will delve further into cleaning up the makefiles now that I understand automake and makefiles much better. There is sooo much legacy architecture and cheap hacks where the same paths are called in different places in the makefiles. Also, would you all agree that I should migrate the current recursive makefiles to just one top-level makefile? You all might also email me/the list a wishlist of how to clean up the source tree and the makefile nasties as they currently exist.
Uhm, yeah. I like the recursive Makefiles. I like being able to work in one directory (e.g. extension) and being able to continually rebuild that directory to get all the warnings and errors out. Also, by building the individual libraries I think it will be easier to create test programs that work with them (e.g. the ones in libnr). So, while I know there is a lot of cruft in the automake files (which should be removed), I think that recursive Makefiles is a good thing.
--Ted
www.barriolinux.net www.augcyl.org gnuva.hispalinux.es www.hispalinux.es gimp.es.gnome.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQFAQi/1+wdOtztJwQkRAvnFAJ0dd5v5jCHJpxcszbiMdFBKP0AC3gCgjoU0 v2+med82R/XNpAJh59MNd+U= =wcTN -----END PGP SIGNATURE-----
SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id%1356&alloc_id438&op%C3%8Ck _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Sun, 29 Feb 2004, Jonathan Phillips wrote:
Currently all icons from the program (non gtk-stock) come from share/icons/*.xpm. Are you asking me to implement a system so that based on the theme of the windowmanager, would change Inkscape accordingly and if there is no folder for themes, then use the default icons?
Does anyone have thoughts on this as well? It seems that this would be a lot of extra work and that the app would benefit from having a unified set of icons that *don't* changed just because of a system's theme. Also, I don't know if this is a very high priority compared with other features. My gut feeling is to not implement this, but if you would like to, then go right ahead.
I agree with your assessment - theming would require additional design thought before it could be implemented, so is best left independent of this refactoring. Once you're done, the work of changing to use themes for icons would be a straightforward project for someone interesting in adding that capability.
(I would assume we could handle themes in an analogous manner to clipart packages or extensions, so maybe the right time to look at it would be after one of those are implemented.)
Bryce
I will do the will of the developers. Any more opinions on this and arguments for and against? I just learned automake while doing this, so I still need to figure out some other things, like how to explicitly recursively copy files from location A to location B and other simple things, but I feel pretty confident in what I know thus far.
The recursive makefiles seem okay to me, and it doesn't seem that difficult to trace their whereabouts. I think I will open a wiki page on our build system, as it is another component that seems like it should be light and demystified if we want to move another direction eventually. Does this sound like a good idea?
Jon
On Sun, 2004-02-29 at 09:13, Ted Gould wrote:
On Sun, 2004-02-29 at 03:59, Jonathan Phillips wrote:
I will delve further into cleaning up the makefiles now that I understand automake and makefiles much better. There is sooo much legacy architecture and cheap hacks where the same paths are called in different places in the makefiles. Also, would you all agree that I should migrate the current recursive makefiles to just one top-level makefile? You all might also email me/the list a wishlist of how to clean up the source tree and the makefile nasties as they currently exist.
Uhm, yeah. I like the recursive Makefiles. I like being able to work in one directory (e.g. extension) and being able to continually rebuild that directory to get all the warnings and errors out. Also, by building the individual libraries I think it will be easier to create test programs that work with them (e.g. the ones in libnr). So, while I know there is a lot of cruft in the automake files (which should be removed), I think that recursive Makefiles is a good thing.
--Ted
On Sun, 29 Feb 2004, Jonathan Phillips wrote:
I will do the will of the developers. Any more opinions on this and arguments for and against? I just learned automake while doing this, so I still need to figure out some other things, like how to explicitly recursively copy files from location A to location B and other simple things, but I feel pretty confident in what I know thus far.
In a previous project we did a tradeoff between recursive and non-recursive make structures after reading this particular article, and ended up going with the recursive make style like how we do it now, for several reasons:
* Compile time was not a big enough issue to need to switch (if it ain't broke...) * We wanted the flexibility of renaming/moving sub-modules without breaking everything * It was our goal to break out modules into independent libraries, so wanted to move towards decentralizing makefiles rather than vice versa.
For inkscape, compile time sounds like it's a bit more of an issue, so the first point isn't as strong. I think we have a similar amount of desire to maintain sub-module flexibility as we rearchitect some areas, although this probably isn't that big of a deal either way. For breaking out into independent libraries, I think actually what we want to aim for is shifting to a core+extension architecture, so that'd be fairly orthogonal to this anyway.
Personally, I like the idea of a single top level Makefile, though I recognize that recursive make is a pretty widespread standard process, and works "Good Enough". If we can definitely prove significantly faster build time through a different scheme, I'd be quite in favor of it, but if not, it'd be less clear. In the end though, as long as I can type 'make' (or an equivalent) at the top level and after some modest amount of time end up with a working executable, I'm happy. ;-)
Bryce
The recursive makefiles seem okay to me, and it doesn't seem that difficult to trace their whereabouts. I think I will open a wiki page on our build system, as it is another component that seems like it should be light and demystified if we want to move another direction eventually. Does this sound like a good idea?
Jon
Ted Gould wrote:
Uhm, yeah. I like the recursive Makefiles. I like being able to work in one directory (e.g. extension) and being able to continually rebuild that directory to get all the warnings and errors out. Also, by building the individual libraries I think it will be easier to create test programs that work with them (e.g. the ones in libnr). So, while I know there is a lot of cruft in the automake files (which should be removed), I think that recursive Makefiles is a good thing.
Non-recursive makes allow for that.
One way is to have makefiles that just work up to find the base, non-recursive one. And if you only want to make a single lib, just do "make libfoo".
Among other issues fixes is proper dependency checking. Also, as "Recursive Make Considered Harmful" points out, most of the time spent is in determining dependencies and checking status over and over. A single unified make gets a proper dependency graph and can speed builds greatly, especially for cases where only a few things have changed.
I've seen the first project I tried it on go from 5+ minutes for a "one-file" change build to under 20 seconds. Plus it started getting all sub-projects right where before they had .phony all over the place.
I should also point out that with recursive makefiles, doing unit tests that depend on files that are not children/in children of their own directory leaves us more or less SOL (because the dependency information isn't properly centralized).
-mental
On Sun, 29 Feb 2004, Jonathan Phillips wrote:
SO I proceeded with the dir. reorg. last night and I have the head compiling and all that. I still have some other little tweaks, but the largest chunk (excluding packaging) has been committed.
Very cool to see this work under way!
Bryce
participants (6)
-
Bryce Harrington -
Jon A. Cruz -
Jonathan Phillips -
MenTaLguY -
Nestor Diaz Valencia -
Ted Gould