Hi All,
The configurable build system has been merged into the latest trunk (>r4120).
This is a significant change which provides considerable flexibility for configuring the operation of the build menu. Please read the manual for the new capabilities ;-) including hidden settings.
To support this extra functionality extra fields have been added to the geany.conf, project and filetype files and some older fields are no longer used. Old format information is still read so that the configuration files do not need to be updated. Older versions of Geany should ignore the new fields and the new Geany does not write old fields so their interaction should be minimal. I have been using both versions for some time without problems.
The semantics of the new system is slightly different to the old one so a mapping had to be chosen between old configuration information and the new system. The mapping chosen is intended to make the semantics of old format configuration files remain the same. The mapping is not documented and should not be relied on as it may be changed without notice to ensure that it meets that intention. Please let us know of any difficulties as this is a complex area and it has been tricky to get the interactions right.
Let us know of any other problems, or good things too of course :-)
Enjoy!!
Cheers Lex
I was wondering if the code in build_init() is used (or only parts of it).
When I had my mess with aborting the build, I added the menu item to build_init(), but it didn't work. I needed to add it to build_menu_item_spec.
Best regards.
2009/8/25 Thomas Martitz thomas.martitz@student.htw-berlin.de:
I was wondering if the code in build_init() is used (or only parts of it).
AFAICT its all used
When I had my mess with aborting the build, I added the menu item to build_init(), but it didn't work.
How did you manage to add it :-) ?
There is nowhere in build_init that creates the menu, it just initialises the default commands and builds the toolbar items. The menu is created by create_build_menu on the first build_menu_update call as per previous design. I'm not sure why it was done that way, I suspect an order of creation issue where one of the other *_inits calls build_menu_update before build_init is run.
I needed to add it to
build_menu_item_spec.
Yes thats where you would add any new "compiled in" menu items since that is the specification of the menu. It lists the "known" build commands and has entries that expand to any extra menu items that are configured by the hidden preferences.
Cheers Lex
Best regards. _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Tue, 25 Aug 2009 14:35:54 +1000, Lex wrote:
Hi All,
The configurable build system has been merged into the latest trunk (>r4120).
And crashes Geany at startup under some circumstances :(.
I happily updated my Geany at work this morning and once I started it, it crashed. http://nopaste.geany.org/p/m5ab611f0 has a short backtrace. Though I didn't manage to find the cause of this crash but I also hadn't much time to look into it.
I zipped my .config/geany directory and tried to reproduce here at home but with no luck. So, I guess it might be related to the project I had opened, unfortunately I didn't copy the project file.
Well, I'll try to debug this a bit more tomorrow.
Lex, maybe you already have an idea what's wrong? I wonder what's about the variable i in the outer for loop, is it initialised at all? Additionally, I noticed the FOREACH_GEANYBUILDCMD_ENTRY () macro which, erm, looks weird. It defines an usual for loop which also uses a variable i. From my experience, I'd say such things can easily lead to weird errors and makes the code less readable.
Btw, I noticed lines 2362 and the following ones are indented with spaces which should be tabs :).
Regards, Enrico
On 25.08.2009 22:53, Enrico Tröger wrote:
I wonder what's about the variable i in the outer for loop, is it initialised at all? Additionally, I noticed the FOREACH_GEANYBUILDCMD_ENTRY () macro which, erm, looks weird. It defines an usual for loop which also uses a variable i. From my experience, I'd say such things can easily lead to weird errors and makes the code less readable.
This FOREACH_GEANYBUILDCMD_ENTRY is from a patch of mine what added the working dir field.
Looping though the enum GeanyBuildCmdEntries members saves a shitload of duplicated code, since often the very same stuff is done for the label, command and working dir field of the config dialog. The macro is just to make it more obvious. The loop is used 13 times alone.
The code is much more readable due to that IMO, and is actually much less error prone than not looping through the enum.
Finally, it doesn't use a variable i, it uses the variable you pass to it.
Best regards.
On Tue, 25 Aug 2009 23:50:24 +0200, Thomas wrote:
On 25.08.2009 22:53, Enrico Tröger wrote:
I wonder what's about the variable i in the outer for loop, is it initialised at all?
Additionally, I noticed the FOREACH_GEANYBUILDCMD_ENTRY () macro which, erm, looks weird. It defines an usual for loop which also uses a variable i. From my experience, I'd say such things can easily lead to weird errors and makes the code less readable.
This FOREACH_GEANYBUILDCMD_ENTRY is from a patch of mine what added the working dir field. [...] The code is much more readable due to that IMO, and is actually much less error prone than not looping through the enum.
I didn't want to say to not loop. I just find this macro unnecessary as it doesn't do anything more than to an usual for loop definition could do as well. In contrary to the foreach_[s]list macros which are indeed very handy.
Finally, it doesn't use a variable i, it uses the variable you pass to it.
My bad, sorry.
Regards, Enrico
2009/8/26 Enrico Tröger enrico.troeger@uvena.de:
On Tue, 25 Aug 2009 14:35:54 +1000, Lex wrote:
Hi All,
The configurable build system has been merged into the latest trunk (>r4120).
And crashes Geany at startup under some circumstances :(.
I happily updated my Geany at work this morning and once I started it, it crashed. http://nopaste.geany.org/p/m5ab611f0 has a short backtrace. Though I didn't manage to find the cause of this crash but I also hadn't much time to look into it.
I zipped my .config/geany directory and tried to reproduce here at home but with no luck. So, I guess it might be related to the project I had opened, unfortunately I didn't copy the project file.
Well, I'll try to debug this a bit more tomorrow.
Lex, maybe you already have an idea what's wrong? I wonder what's about the variable i in the outer for loop, is it initialised at all?
No its not initialised, but it shouldn't be a variable i, S/B 1, see attached patch. Removes the now unused variable too.
Additionally, I noticed the FOREACH_GEANYBUILDCMD_ENTRY () macro which, erm, looks weird. It defines an usual for loop which also uses a variable i. From my experience, I'd say such things can easily lead to weird errors and makes the code less readable.
The decision on macro or not is between you and Thomas, as a C++ programmer I lean towards the "macros are evil" (but occasionally necessary) approach. If the macro stays I suggest that the uses of the argument in the macro body be enclosed in (), this is a standard way to reduce problems in case arguments are expressions.
Btw, I noticed lines 2362 and the following ones are indented with spaces which should be tabs :).
Fixed in patch also. Is there a "convert all indents to Geany standard" command?
Do you have a problem if I commit bugfixes to build.c and build.h in trunk (I'll commit to no other files)?
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Wed, 26 Aug 2009 15:09:44 +1000 Lex Trotman elextr@gmail.com wrote:
Fixed in patch also. Is there a "convert all indents to Geany standard" command?
There's Document->Replace Spaces by Tabs.
Do you have a problem if I commit bugfixes to build.c and build.h in trunk (I'll commit to no other files)?
Fine with me, so long as the code style conforms. Enrico?
Regards, Nick
On Wed, 26 Aug 2009 16:12:19 +0100, Nick wrote:
Do you have a problem if I commit bugfixes to build.c and build.h in trunk (I'll commit to no other files)?
Fine with me, so long as the code style conforms. Enrico?
Yup, it's fine.
Regards, Enrico
I've assumed ChangeLog as well :-)
2009/8/27 Enrico Tröger enrico.troeger@uvena.de:
On Wed, 26 Aug 2009 16:12:19 +0100, Nick wrote:
Do you have a problem if I commit bugfixes to build.c and build.h in trunk (I'll commit to no other files)?
Fine with me, so long as the code style conforms. Enrico?
Yup, it's fine.
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
2009/8/27 Nick Treleaven nick.treleaven@btinternet.com:
On Wed, 26 Aug 2009 15:09:44 +1000 Lex Trotman elextr@gmail.com wrote:
Fixed in patch also. Is there a "convert all indents to Geany standard" command?
There's Document->Replace Spaces by Tabs.
Doh! done on all of build.c.
Do you have a problem if I commit bugfixes to build.c and build.h in trunk (I'll commit to no other files)?
Fine with me, so long as the code style conforms. Enrico?
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Thu, 27 Aug 2009 09:46:30 +1000 Lex Trotman elextr@gmail.com wrote:
Fixed in patch also. Is there a "convert all indents to Geany standard" command?
There's Document->Replace Spaces by Tabs.
Doh! done on all of build.c.
Hmm, perhaps I should have answered No ;-) That command seems to have messed up the spaces for alignment in build.c.
Regards, Nick
2009/8/27 Nick Treleaven nick.treleaven@btinternet.com:
On Thu, 27 Aug 2009 09:46:30 +1000 Lex Trotman elextr@gmail.com wrote:
Fixed in patch also. Is there a "convert all indents to Geany standard" command?
There's Document->Replace Spaces by Tabs.
Doh! done on all of build.c.
Hmm, perhaps I should have answered No ;-) That command seems to have messed up the spaces for alignment in build.c.
Doh!, well I guess it will get cleaned up over time.
Lex
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Fri, 28 Aug 2009 17:55:12 +1000, Lex wrote:
2009/8/27 Nick Treleaven nick.treleaven@btinternet.com:
On Thu, 27 Aug 2009 09:46:30 +1000 Lex Trotman elextr@gmail.com wrote:
Fixed in patch also. Is there a "convert all indents to Geany standard" command?
There's Document->Replace Spaces by Tabs.
Doh! done on all of build.c.
Hmm, perhaps I should have answered No ;-) That command seems to have messed up the spaces for alignment in build.c.
Doh!, well I guess it will get cleaned up over time.
Or just 'svn revert' :)
Regards, Enrico
On Wed, 26 Aug 2009 15:09:44 +1000 Lex Trotman elextr@gmail.com wrote:
I wonder what's about the variable i in the outer for loop, is it initialised at all?
No its not initialised, but it shouldn't be a variable i, S/B 1, see attached patch. Removes the now unused variable too.
Applied in SVN, thanks. I used GEANY_BC_COMMAND instead of '1' to make it clear.
Regards, Nick
On Wed, 26 Aug 2009 16:33:22 +0100, Nick wrote:
On Wed, 26 Aug 2009 15:09:44 +1000 Lex Trotman elextr@gmail.com wrote:
I wonder what's about the variable i in the outer for loop, is it initialised at all?
No its not initialised, but it shouldn't be a variable i, S/B 1, see attached patch. Removes the now unused variable too.
Applied in SVN, thanks. I used GEANY_BC_COMMAND instead of '1' to make it clear.
And works fine, thanks.
Regards, Enrico
2009/8/27 Nick Treleaven nick.treleaven@btinternet.com:
On Wed, 26 Aug 2009 15:09:44 +1000 Lex Trotman elextr@gmail.com wrote:
I wonder what's about the variable i in the outer for loop, is it initialised at all?
No its not initialised, but it shouldn't be a variable i, S/B 1, see attached patch. Removes the now unused variable too.
Applied in SVN, thanks. I used GEANY_BC_COMMAND instead of '1' to make
Excellent!!! I must have read that damn i as a 1 fifteen times yesterday.
it clear.
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Wed, 26 Aug 2009 15:09:44 +1000, Lex wrote:
2009/8/26 Enrico Tröger enrico.troeger@uvena.de:
On Tue, 25 Aug 2009 14:35:54 +1000, Lex wrote:
Hi All,
The configurable build system has been merged into the latest trunk (>r4120).
And crashes Geany at startup under some circumstances :(.
I happily updated my Geany at work this morning and once I started it, it crashed. http://nopaste.geany.org/p/m5ab611f0 has a short backtrace. Though I didn't manage to find the cause of this crash but I also hadn't much time to look into it.
I zipped my .config/geany directory and tried to reproduce here at home but with no luck. So, I guess it might be related to the project I had opened, unfortunately I didn't copy the project file.
Well, I'll try to debug this a bit more tomorrow.
Lex, maybe you already have an idea what's wrong? I wonder what's about the variable i in the outer for loop, is it initialised at all?
No its not initialised, but it shouldn't be a variable i, S/B 1, see attached patch. Removes the now unused variable too.
Additionally, I noticed the FOREACH_GEANYBUILDCMD_ENTRY () macro which, erm, looks weird. It defines an usual for loop which also uses a variable i. From my experience, I'd say such things can easily lead to weird errors and makes the code less readable.
The decision on macro or not is between you and Thomas, as a C++ programmer I lean towards the "macros are evil" (but occasionally necessary) approach.
I would like to remove the macro as I really don't see how it helps. If there are no objections (except from Thomas which I expect :), I will remove the macro soon.
Additionally, while searching for uses of this macro, I found several lines which were indented with spaces instead of tabs. That's not critical at all, just want to mention it. I guess this came by Thomas's patch. But it's easily fixable, so no big deal.
If the macro stays I suggest that the uses of the argument in the macro body be enclosed in (), this is a standard way to reduce problems in case arguments are expressions.
Yes, this is the very least.
Regards, Enrico
On Tue, 25 Aug 2009 14:35:54 +1000 Lex Trotman elextr@gmail.com wrote:
This is a significant change which provides considerable flexibility for configuring the operation of the build menu. Please read the manual for the new capabilities ;-) including hidden settings.
...
Let us know of any other problems, or good things too of course :-)
I've been using the new build code today, I like the extra configurability, thanks Lex (and Thomas) :)
I noticed some things though:
1. Make keybindings don't work properly. The Make All keybinding seems to run the Compile command (e.g. for C source files). The Make Object keybinding doesn't do anything at all.
2. I think the current working directory should be used by default for Make Object, not the project directory - presumably that doesn't work even for a non-recursive makefile as the relative path isn't there. (I mean for source files in a subdirectory from the project base path). This would preserve pre-merge behaviour.
3. My Compile keybinding is set to F8, but the menu accelerator doesn't seem to get set. The other build KB accels seem to be there OK.
Regards, Nick
On Wed, 26 Aug 2009 18:43:52 +0100, Nick wrote:
On Tue, 25 Aug 2009 14:35:54 +1000 Lex Trotman elextr@gmail.com wrote:
This is a significant change which provides considerable flexibility for configuring the operation of the build menu. Please read the manual for the new capabilities ;-) including hidden settings.
...
Let us know of any other problems, or good things too of course :-)
I've been using the new build code today, I like the extra configurability, thanks Lex (and Thomas) :)
I noticed some things though:
- Make keybindings don't work properly. The Make All keybinding seems
to run the Compile command (e.g. for C source files). The Make Object keybinding doesn't do anything at all.
- I think the current working directory should be used by default for
Make Object, not the project directory - presumably that doesn't work even for a non-recursive makefile as the relative path isn't there. (I mean for source files in a subdirectory from the project base path). This would preserve pre-merge behaviour.
Additionally, the Run command behaviour has changed: it uses something different as working directory as before. In my "geany" project, I set _build_/default/geany -v -c ... as Run command and this was executed in the project's base directory before, now I get a file not found error, so it is obviously using something different. After I set %p in the build settings as working directory it worked, but for consistency with the pre-merge behaviour, this should be default (for projects).
Regards, Enrico
On Wed, 26 Aug 2009 23:05:23 +0200, Enrico wrote:
On Wed, 26 Aug 2009 18:43:52 +0100, Nick wrote:
On Tue, 25 Aug 2009 14:35:54 +1000 Lex Trotman elextr@gmail.com wrote:
This is a significant change which provides considerable flexibility for configuring the operation of the build menu. Please read the manual for the new capabilities ;-) including hidden settings.
...
Let us know of any other problems, or good things too of course :-)
I've been using the new build code today, I like the extra configurability, thanks Lex (and Thomas) :)
I noticed some things though:
- Make keybindings don't work properly. The Make All keybinding seems
to run the Compile command (e.g. for C source files). The Make Object keybinding doesn't do anything at all.
- I think the current working directory should be used by default for
Make Object, not the project directory - presumably that doesn't work even for a non-recursive makefile as the relative path isn't there. (I mean for source files in a subdirectory from the project base path). This would preserve pre-merge behaviour.
Additionally, the Run command behaviour has changed: it uses something different as working directory as before. In my "geany" project, I set _build_/default/geany -v -c ... as Run command and this was executed in the project's base directory before, now I get a file not found error, so it is obviously using something different. After I set %p in the build settings as working directory it worked, but for consistency with the pre-merge behaviour, this should be default (for projects).
One more thing, sorry. I remember we talked about removing the second Run command which was special for LaTeX. Then you added the second Run command generally (which I actually do like since today because I had an use case for :D). But we lost the keybinding for the second Run command anyway. Was this a mistake or on purpose?
It might be a missed something, if so, don't beat too much...:).
Regards, Enrico
2009/8/27 Enrico Tröger enrico.troeger@uvena.de:
On Wed, 26 Aug 2009 23:05:23 +0200, Enrico wrote:
On Wed, 26 Aug 2009 18:43:52 +0100, Nick wrote:
On Tue, 25 Aug 2009 14:35:54 +1000 Lex Trotman elextr@gmail.com wrote:
This is a significant change which provides considerable flexibility for configuring the operation of the build menu. Please read the manual for the new capabilities ;-) including hidden settings.
...
Let us know of any other problems, or good things too of course :-)
I've been using the new build code today, I like the extra configurability, thanks Lex (and Thomas) :)
I noticed some things though:
- Make keybindings don't work properly. The Make All keybinding seems
to run the Compile command (e.g. for C source files). The Make Object keybinding doesn't do anything at all.
- I think the current working directory should be used by default for
Make Object, not the project directory - presumably that doesn't work even for a non-recursive makefile as the relative path isn't there. (I mean for source files in a subdirectory from the project base path). This would preserve pre-merge behaviour.
Additionally, the Run command behaviour has changed: it uses something different as working directory as before. In my "geany" project, I set _build_/default/geany -v -c ... as Run command and this was executed in the project's base directory before, now I get a file not found error, so it is obviously using something different. After I set %p in the build settings as working directory it worked, but for consistency with the pre-merge behaviour, this should be default (for projects).
One more thing, sorry. I remember we talked about removing the second Run command which was special for LaTeX. Then you added the second Run command generally (which I actually do like since today because I had an use case for :D). But we lost the keybinding for the second Run command anyway. Was this a mistake or on purpose?
It might be a missed something, if so, don't beat too much...:).
No beatings necessary, The extra execute menu item is no longer a known command, its an variable command. Only the known commands have keybindings for now.
This is because so much of the keybindings code depends on the fact that it knows all the actions that keys can be bound to and their names. So I could not see a simple way of handling variable menu items in the keybinding dialog and on load/save.
Any suggestions how to handle the variable menu items welcome because all the variable build commands should be able to be bound to keys. Remember the number of variable items is itself variable.
Cheers Lex
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Thu, 27 Aug 2009 10:54:16 +1000, Lex wrote:
2009/8/27 Enrico Tröger enrico.troeger@uvena.de:
On Wed, 26 Aug 2009 23:05:23 +0200, Enrico wrote:
On Wed, 26 Aug 2009 18:43:52 +0100, Nick wrote:
On Tue, 25 Aug 2009 14:35:54 +1000 Lex Trotman elextr@gmail.com wrote:
This is a significant change which provides considerable flexibility for configuring the operation of the build menu. Please read the manual for the new capabilities ;-) including hidden settings.
...
Let us know of any other problems, or good things too of course :-)
I've been using the new build code today, I like the extra configurability, thanks Lex (and Thomas) :)
I noticed some things though:
- Make keybindings don't work properly. The Make All keybinding
seems to run the Compile command (e.g. for C source files). The Make Object keybinding doesn't do anything at all.
- I think the current working directory should be used by default
for Make Object, not the project directory - presumably that doesn't work even for a non-recursive makefile as the relative path isn't there. (I mean for source files in a subdirectory from the project base path). This would preserve pre-merge behaviour.
Additionally, the Run command behaviour has changed: it uses something different as working directory as before. In my "geany" project, I set _build_/default/geany -v -c ... as Run command and this was executed in the project's base directory before, now I get a file not found error, so it is obviously using something different. After I set %p in the build settings as working directory it worked, but for consistency with the pre-merge behaviour, this should be default (for projects).
One more thing, sorry. I remember we talked about removing the second Run command which was special for LaTeX. Then you added the second Run command generally (which I actually do like since today because I had an use case for :D). But we lost the keybinding for the second Run command anyway. Was this a mistake or on purpose?
It might be a missed something, if so, don't beat too much...:).
No beatings necessary, The extra execute menu item is no longer a known command, its an variable command. Only the known commands have keybindings for now.
Alright, got it. Thanks.
Regards, Enrico
2009/8/27 Enrico Tröger enrico.troeger@uvena.de:
On Wed, 26 Aug 2009 18:43:52 +0100, Nick wrote:
On Tue, 25 Aug 2009 14:35:54 +1000 Lex Trotman elextr@gmail.com wrote:
This is a significant change which provides considerable flexibility for configuring the operation of the build menu. Please read the manual for the new capabilities ;-) including hidden settings.
...
Let us know of any other problems, or good things too of course :-)
I've been using the new build code today, I like the extra configurability, thanks Lex (and Thomas) :)
I noticed some things though:
- Make keybindings don't work properly. The Make All keybinding seems
to run the Compile command (e.g. for C source files). The Make Object keybinding doesn't do anything at all.
- I think the current working directory should be used by default for
Make Object, not the project directory - presumably that doesn't work even for a non-recursive makefile as the relative path isn't there. (I mean for source files in a subdirectory from the project base path). This would preserve pre-merge behaviour.
Additionally, the Run command behaviour has changed: it uses something different as working directory as before. In my "geany" project, I set _build_/default/geany -v -c ... as Run command and this was executed in the project's base directory before, now I get a file not found error, so it is obviously using something different. After I set %p in the build settings as working directory it worked, but for consistency with the pre-merge behaviour, this should be default (for projects).
Ahh, I had in fact misunderstood the usage of the project base directory, after reading the manual s-l-o-w-l-y i think the version in SVN now should follow the manual better. That includes removing the previous "fix" to make custom as it now makes sense to use basedir.
In SVN twice.
It took two goes to get it right, there are 16 combinations of settings influencing this behavior and each requires manually editing the respective config files, so please excuse me if I miss testing a combination now and then :-) ... at least I found it before anyone else did ;-)
Cheers Lex
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Thu, 27 Aug 2009 13:56:47 +1000, Lex wrote:
It took two goes to get it right, there are 16 combinations of settings influencing this behavior and each requires manually editing the respective config files, so please excuse me if I miss testing a combination now and then :-) ... at least I found it before anyone
Haha, no worries. I'm much better in committing code which is not tested or not well tested enough...it just happens.
Regards, Enrico
2009/8/27 Nick Treleaven nick.treleaven@btinternet.com:
On Tue, 25 Aug 2009 14:35:54 +1000 Lex Trotman elextr@gmail.com wrote:
This is a significant change which provides considerable flexibility for configuring the operation of the build menu. Please read the manual for the new capabilities ;-) including hidden settings.
...
Let us know of any other problems, or good things too of course :-)
I've been using the new build code today, I like the extra configurability, thanks Lex (and Thomas) :)
I noticed some things though:
- Make keybindings don't work properly. The Make All keybinding seems
to run the Compile command (e.g. for C source files). The Make Object keybinding doesn't do anything at all.
Patch for keybindings.c attached
- I think the current working directory should be used by default for
Make Object, not the project directory - presumably that doesn't work even for a non-recursive makefile as the relative path isn't there. (I mean for source files in a subdirectory from the project base path). This would preserve pre-merge behaviour.
Fixed in SVN & for make custom for which the same argument holds.
- My Compile keybinding is set to F8, but the menu accelerator doesn't
seem to get set. The other build KB accels seem to be there OK.
fixed in SVN
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
and this time with the patch ;-)
Cheers Lex
2009/8/27 Lex Trotman elextr@gmail.com:
2009/8/27 Nick Treleaven nick.treleaven@btinternet.com:
On Tue, 25 Aug 2009 14:35:54 +1000 Lex Trotman elextr@gmail.com wrote:
This is a significant change which provides considerable flexibility for configuring the operation of the build menu. Please read the manual for the new capabilities ;-) including hidden settings.
...
Let us know of any other problems, or good things too of course :-)
I've been using the new build code today, I like the extra configurability, thanks Lex (and Thomas) :)
I noticed some things though:
- Make keybindings don't work properly. The Make All keybinding seems
to run the Compile command (e.g. for C source files). The Make Object keybinding doesn't do anything at all.
Patch for keybindings.c attached
- I think the current working directory should be used by default for
Make Object, not the project directory - presumably that doesn't work even for a non-recursive makefile as the relative path isn't there. (I mean for source files in a subdirectory from the project base path). This would preserve pre-merge behaviour.
Fixed in SVN & for make custom for which the same argument holds.
- My Compile keybinding is set to F8, but the menu accelerator doesn't
seem to get set. The other build KB accels seem to be there OK.
fixed in SVN
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Thu, 27 Aug 2009 11:10:51 +1000 Lex Trotman elextr@gmail.com wrote:
- Make keybindings don't work properly. The Make All keybinding seems
to run the Compile command (e.g. for C source files). The Make Object keybinding doesn't do anything at all.
Patch for keybindings.c attached
Applied, thanks.
- I think the current working directory should be used by default for
Make Object, not the project directory - presumably that doesn't work even for a non-recursive makefile as the relative path isn't there. (I mean for source files in a subdirectory from the project base path). This would preserve pre-merge behaviour.
Fixed in SVN
Thanks.
Personally I prefer the old way of using %p rather than having to press the button to set the make paths, why did it change?
& for make custom for which the same argument holds.
- My Compile keybinding is set to F8, but the menu accelerator doesn't
seem to get set. The other build KB accels seem to be there OK.
fixed in SVN
Thanks again ;-)
Regards, Nick
2009/8/27 Nick Treleaven nick.treleaven@btinternet.com:
On Thu, 27 Aug 2009 11:10:51 +1000 Lex Trotman elextr@gmail.com wrote:
- Make keybindings don't work properly. The Make All keybinding seems
to run the Compile command (e.g. for C source files). The Make Object keybinding doesn't do anything at all.
Patch for keybindings.c attached
Applied, thanks.
- I think the current working directory should be used by default for
Make Object, not the project directory - presumably that doesn't work even for a non-recursive makefile as the relative path isn't there. (I mean for source files in a subdirectory from the project base path). This would preserve pre-merge behaviour.
Fixed in SVN
Thanks.
Personally I prefer the old way of using %p rather than having to press the button to set the make paths, why did it change?
Sorry I'm not sure what you are talking about, which button? AFAICT the change didn't touch any button? I are confused.
& for make custom for which the same argument holds.
- My Compile keybinding is set to F8, but the menu accelerator doesn't
seem to get set. The other build KB accels seem to be there OK.
fixed in SVN
Thanks again ;-)
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Fri, 28 Aug 2009 17:57:00 +1000 Lex Trotman elextr@gmail.com wrote:
Personally I prefer the old way of using %p rather than having to press the button to set the make paths, why did it change?
Sorry I'm not sure what you are talking about, which button? AFAICT the change didn't touch any button? I are confused.
Don't worry, it might not be related to the recent changes. What I meant was the working directory fields for make were shown as "%p", but now they are shown as the full base path "/home/nmt/svn/geany".
This is (perhaps only) the case for my 'geany' project though, so perhaps just an SVN upgrading issue.
Regards, Nick
2009/8/28 Nick Treleaven nick.treleaven@btinternet.com:
On Fri, 28 Aug 2009 17:57:00 +1000 Lex Trotman elextr@gmail.com wrote:
Personally I prefer the old way of using %p rather than having to press the button to set the make paths, why did it change?
Sorry I'm not sure what you are talking about, which button? AFAICT the change didn't touch any button? I are confused.
Don't worry, it might not be related to the recent changes. What I meant was the working directory fields for make were shown as "%p", but now they are shown as the full base path "/home/nmt/svn/geany".
Oh, see what you mean, yes that is caused by the latest change,
I thought showing the actual directory was better, easy to change it to just check the result of project_get_base_path & if its not null & put %p (like it puts %d if it is null).
I guess its more symmetric to use %p or %d vs path or %d, fix it tomorrow unless any disagreement.
Cheers Lex
This is (perhaps only) the case for my 'geany' project though, so perhaps just an SVN upgrading issue.
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Tue, 25 Aug 2009 14:35:54 +1000 Lex Trotman elextr@gmail.com wrote:
Let us know of any other problems
Running Make on a new unsaved document (no filename) causes warnings and may crash on Windows using %s for a NULL string. Maybe disable Make menu items for new documents?
Regards, Nick
2009/9/1 Nick Treleaven nick.treleaven@btinternet.com:
On Tue, 25 Aug 2009 14:35:54 +1000 Lex Trotman elextr@gmail.com wrote:
Let us know of any other problems
Running Make on a new unsaved document (no filename) causes warnings and may crash on Windows using %s for a NULL string. Maybe disable Make menu items for new documents?
No, disabling isn't right, the make commands are not inherently dependent on the document, they can be configured to be totally independent of it, in fact make often runs on the source *tree* and doesn't care what document is current.
The thing is to find the problem.
Since I can't build on windows, can you provide any more feedback (a backtrace or something) on what actually is complaining of a NULL. I can see several possible culprits although they all *should* be protected from nulls, but they should not be windows dependent, why can't it fail on Linux so I can see??? Grouch Grump Gripe...
Cheers Lex
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Tue, 1 Sep 2009 17:42:47 +1000 Lex Trotman elextr@gmail.com wrote:
Running Make on a new unsaved document (no filename) causes warnings and may crash on Windows using %s for a NULL string. Maybe disable Make menu items for new documents?
No, disabling isn't right, the make commands are not inherently dependent on the document, they can be configured to be totally independent of it, in fact make often runs on the source *tree* and doesn't care what document is current.
OK, but what if the command is configured to use the current file's directory and the current file doesn't have a filename?
The thing is to find the problem.
Since I can't build on windows, can you provide any more feedback (a backtrace or something) on what actually is complaining of a NULL. I can see several possible culprits although they all *should* be protected from nulls, but they should not be windows dependent, why can't it fail on Linux so I can see??? Grouch Grump Gripe...
I haven't tried it on Windows, but from the messages window first line I saw:
/usr/bin/make (in directory: (null))
After running Make All on a new document.
Also in the terminal there are tons of warnings from GLib:
(geany:2835): GLib-CRITICAL **: g_path_get_basename: assertion `file_name != NULL' failed
(geany:2835): GLib-CRITICAL **: g_path_get_dirname: assertion `file_name != NULL' failed
** (geany:2835): CRITICAL **: utils_remove_ext_from_filename: assertion `filename != NULL' failed
Regards, Nick
2009/9/2 Nick Treleaven nick.treleaven@btinternet.com:
On Tue, 1 Sep 2009 17:42:47 +1000 Lex Trotman elextr@gmail.com wrote:
Running Make on a new unsaved document (no filename) causes warnings and may crash on Windows using %s for a NULL string. Maybe disable Make menu items for new documents?
No, disabling isn't right, the make commands are not inherently dependent on the document, they can be configured to be totally independent of it, in fact make often runs on the source *tree* and doesn't care what document is current.
OK, but what if the command is configured to use the current file's directory and the current file doesn't have a filename?
Then we should not fail and should give a useful status message, eg "Build not run, requires a current directory" or some such
The thing is to find the problem.
Since I can't build on windows, can you provide any more feedback (a backtrace or something) on what actually is complaining of a NULL. I can see several possible culprits although they all *should* be protected from nulls, but they should not be windows dependent, why can't it fail on Linux so I can see??? Grouch Grump Gripe...
I haven't tried it on Windows, but from the messages window first line
I misread that you were running on windows :-)
I saw:
/usr/bin/make (in directory: (null))
After running Make All on a new document.
Also in the terminal there are tons of warnings from GLib:
Yeah clearly somewhere is bypassing the tests of null directory, hopefully I'll get time to look later in the week.
(geany:2835): GLib-CRITICAL **: g_path_get_basename: assertion `file_name != NULL' failed
(geany:2835): GLib-CRITICAL **: g_path_get_dirname: assertion `file_name != NULL' failed
** (geany:2835): CRITICAL **: utils_remove_ext_from_filename: assertion `filename != NULL' failed
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Tue, 1 Sep 2009 17:42:47 +1000, Lex wrote:
2009/9/1 Nick Treleaven nick.treleaven@btinternet.com:
On Tue, 25 Aug 2009 14:35:54 +1000 Lex Trotman elextr@gmail.com wrote:
Let us know of any other problems
Running Make on a new unsaved document (no filename) causes warnings and may crash on Windows using %s for a NULL string. Maybe disable Make menu items for new documents?
No, disabling isn't right, the make commands are not inherently dependent on the document, they can be configured to be totally independent of it, in fact make often runs on the source *tree* and doesn't care what document is current.
The thing is to find the problem.
Since I can't build on windows, can you provide any more feedback (a backtrace or something) on what actually is complaining of a NULL. I
On Windows, printf() with arguments being NULL crashes. No idea why but it does, mostly. For example things like:
char *s = NULL; g_message("This is a %s string.", s);
is likely to crash. And this is why Nick suggested to early eliminate such cases. It's harmless on non-Windows systems where you just see a "(null)" string instead. On Windows, you see the operating systems crash dialog...
And fixing the warnings Nick mentioned is a very step to pretend such cases.
Regards, Enrico
2009/9/2 Enrico Tröger enrico.troeger@uvena.de:
On Tue, 1 Sep 2009 17:42:47 +1000, Lex wrote:
2009/9/1 Nick Treleaven nick.treleaven@btinternet.com:
On Tue, 25 Aug 2009 14:35:54 +1000 Lex Trotman elextr@gmail.com wrote:
Let us know of any other problems
Running Make on a new unsaved document (no filename) causes warnings and may crash on Windows using %s for a NULL string. Maybe disable Make menu items for new documents?
No, disabling isn't right, the make commands are not inherently dependent on the document, they can be configured to be totally independent of it, in fact make often runs on the source *tree* and doesn't care what document is current.
The thing is to find the problem.
Since I can't build on windows, can you provide any more feedback (a backtrace or something) on what actually is complaining of a NULL. I
On Windows, printf() with arguments being NULL crashes. No idea why but it does, mostly. For example things like:
char *s = NULL; g_message("This is a %s string.", s);
is likely to crash. And this is why Nick suggested to early eliminate such cases. It's harmless on non-Windows systems where you just see a "(null)" string instead. On Windows, you see the operating systems crash dialog...
And fixing the warnings Nick mentioned is a very step to pretend such cases.
Regards, Enrico
Enrico,
Thanks for the explanation, as I replied to Nick I had misunderstood that he was running on windows and the problem didn't show on Linux.
Will look at where a NULL is escaping detection.
Cheers Lex
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
2009/9/2 Lex Trotman elextr@gmail.com:
2009/9/2 Enrico Tröger enrico.troeger@uvena.de:
On Tue, 1 Sep 2009 17:42:47 +1000, Lex wrote:
2009/9/1 Nick Treleaven nick.treleaven@btinternet.com:
On Tue, 25 Aug 2009 14:35:54 +1000 Lex Trotman elextr@gmail.com wrote:
Let us know of any other problems
Running Make on a new unsaved document (no filename) causes warnings and may crash on Windows using %s for a NULL string. Maybe disable Make menu items for new documents?
No, disabling isn't right, the make commands are not inherently dependent on the document, they can be configured to be totally independent of it, in fact make often runs on the source *tree* and doesn't care what document is current.
The thing is to find the problem.
Since I can't build on windows, can you provide any more feedback (a backtrace or something) on what actually is complaining of a NULL. I
On Windows, printf() with arguments being NULL crashes. No idea why but it does, mostly. For example things like:
char *s = NULL; g_message("This is a %s string.", s);
is likely to crash. And this is why Nick suggested to early eliminate such cases. It's harmless on non-Windows systems where you just see a "(null)" string instead. On Windows, you see the operating systems crash dialog...
And fixing the warnings Nick mentioned is a very step to pretend such cases.
Regards, Enrico
Enrico,
Thanks for the explanation, as I replied to Nick I had misunderstood that he was running on windows and the problem didn't show on Linux.
Will look at where a NULL is escaping detection.
Cheers Lex
Hi Guys,
I think I've got them all. But no guarantees ;-)
Now also gives a status message when failing to run a command because of no working directory, ie no document filename or configured working directory.
Cheers Lex
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Thu, 3 Sep 2009 14:38:23 +1000 Lex Trotman elextr@gmail.com wrote:
Running Make on a new unsaved document (no filename) causes warnings and may crash on Windows using %s for a NULL string. Maybe disable Make menu items for new documents?
No, disabling isn't right, the make commands are not inherently
...
On Windows, printf() with arguments being NULL crashes. No idea why but it does, mostly.
...
I think I've got them all. But no guarantees ;-)
Now also gives a status message when failing to run a command because of no working directory, ie no document filename or configured working directory.
Thanks. There were 2 free's of possibly uninitialized pointers in build_replace_placeholder() but I fixed them after a crash ;-)
Regards, Nick
On Tue, 25 Aug 2009 14:35:54 +1000 Lex Trotman elextr@gmail.com wrote:
Hi All,
The configurable build system has been merged into the latest trunk (>r4120).
This is a significant change which provides considerable flexibility for configuring the operation of the build menu. Please read the manual for the new capabilities ;-) including hidden settings.
To support this extra functionality extra fields have been added to the geany.conf, project and filetype files and some older fields are no longer used. Old format information is still read so that the configuration files do not need to be updated. Older versions of Geany should ignore the new fields and the new Geany does not write old fields so their interaction should be minimal. I have been using both versions for some time without problems.
The semantics of the new system is slightly different to the old one so a mapping had to be chosen between old configuration information and the new system. The mapping chosen is intended to make the semantics of old format configuration files remain the same. The mapping is not documented and should not be relied on as it may be changed without notice to ensure that it meets that intention. Please let us know of any difficulties as this is a complex area and it has been tricky to get the interactions right.
Let us know of any other problems, or good things too of course :-)
Enjoy!!
Cheers Lex _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Regards, Nick
Sorry, Ctrl-Enter in Sylpheed is not a good default shortcut for Send!
On Mon, 31 Aug 2009 17:37:39 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
Sorry, Ctrl-Enter in Sylpheed is not a good default shortcut for Send!
I think what Pidgin and others are doing using Ctrl+Strg not for sending by default is a bad idea ;D
Cheers, Frank
Hi, I just noticed that all user filetypes files are always created and saved, just by quitting Geany. The previous behaviour was to only create/save a filetypes file if the user had pressed OK in the Build Commands dialog *for that filetype*. Could this be implemented?
Regards, Nick
2009/9/1 Nick Treleaven nick.treleaven@btinternet.com:
Hi, I just noticed that all user filetypes files are always created and saved, just by quitting Geany. The previous behaviour was to only create/save a filetypes file if the user had pressed OK in the Build Commands dialog *for that filetype*. Could this be implemented?
Yes. I think it should be, but its mildly non-trivial.
It would require extra fields in GeanyFiletypesPrivate (? and GeanyFiletype ?) to record if any of the regexes are changed so that writting of the file can be prevented only if the regex isn't changed. And the dialogs need additions to set them.
Then some way is needed for build_save_command_grp to signal if it wrote or removed any fields (current return is written only, not removal & needs to stay that) so that build_save_command can return if anything is changed to the places that write the config file so that they know if they need to write the file or not.
I'm probably busy for the next few days, do it later this week.
Cheers Lex
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Tue, 1 Sep 2009 17:22:51 +1000 Lex Trotman elextr@gmail.com wrote:
I just noticed that all user filetypes files are always created and saved, just by quitting Geany. The previous behaviour was to only create/save a filetypes file if the user had pressed OK in the Build Commands dialog *for that filetype*. Could this be implemented?
Yes. I think it should be, but its mildly non-trivial.
It would require extra fields in GeanyFiletypesPrivate (? and GeanyFiletype ?) to record if any of the regexes are changed so that writting of the file can be prevented only if the regex isn't changed. And the dialogs need additions to set them.
That's not necessary IMO - surely if the dialog is never shown or Cancel is pressed, nothing is changed? We could just set a private flag for the filetype if OK was clicked.
Regards, Nick
On Tue, 1 Sep 2009 15:37:51 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
I just noticed that all user filetypes files are always created and saved, just by quitting Geany. The previous behaviour was to only create/save a filetypes file if the user had pressed OK in the Build Commands dialog *for that filetype*. Could this be implemented?
Yes. I think it should be, but its mildly non-trivial.
It would require extra fields in GeanyFiletypesPrivate (? and GeanyFiletype ?) to record if any of the regexes are changed so that writting of the file can be prevented only if the regex isn't changed. And the dialogs need additions to set them.
That's not necessary IMO - surely if the dialog is never shown or Cancel is pressed, nothing is changed? We could just set a private flag for the filetype if OK was clicked.
Obviously this way you may get a false positive if the user didn't change anything and just pressed OK but this makes it much easier to implement and avoids a lot of unnecessary files on disk.
Regards, Nick
On Tue, 1 Sep 2009 15:39:09 +0100, Nick wrote:
On Tue, 1 Sep 2009 15:37:51 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
I just noticed that all user filetypes files are always created and saved, just by quitting Geany. The previous behaviour was to only create/save a filetypes file if the user had pressed OK in the Build Commands dialog *for that filetype*. Could this be implemented?
Yes. I think it should be, but its mildly non-trivial.
It would require extra fields in GeanyFiletypesPrivate (? and GeanyFiletype ?) to record if any of the regexes are changed so that writting of the file can be prevented only if the regex isn't changed. And the dialogs need additions to set them.
That's not necessary IMO - surely if the dialog is never shown or Cancel is pressed, nothing is changed? We could just set a private flag for the filetype if OK was clicked.
Obviously this way you may get a false positive if the user didn't change anything and just pressed OK but this makes it much easier to implement and avoids a lot of unnecessary files on disk.
I fully agree here. The previous behaviour where only real changes were written into user config files were better.
Regards, Enrico
2009/9/2 Enrico Tröger enrico.troeger@uvena.de:
On Tue, 1 Sep 2009 15:39:09 +0100, Nick wrote:
On Tue, 1 Sep 2009 15:37:51 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
I just noticed that all user filetypes files are always created and saved, just by quitting Geany. The previous behaviour was to only create/save a filetypes file if the user had pressed OK in the Build Commands dialog *for that filetype*. Could this be implemented?
Yes. I think it should be, but its mildly non-trivial.
As I said above, it should be implemented!!
It would require extra fields in GeanyFiletypesPrivate (? and GeanyFiletype ?) to record if any of the regexes are changed so that writting of the file can be prevented only if the regex isn't changed. And the dialogs need additions to set them.
That's not necessary IMO - surely if the dialog is never shown or Cancel is pressed, nothing is changed? We could just set a private flag for the filetype if OK was clicked.
Obviously this way you may get a false positive if the user didn't change anything and just pressed OK but this makes it much easier to implement and avoids a lot of unnecessary files on disk.
If this is ok, then happy to use simpler solution :-)
I fully agree here. The previous behaviour where only real changes were written into user config files were better.
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Nick, Enrico,
SVN version should now only save config files when needed. I now vaguely remember knowing about the problem, certainly I had made the function that reads the build commands dialog return a bool true if anything changed.
But I did nothing with it (TODO list failure?), so now its used.
Cheers Lex
On Thu, 3 Sep 2009 13:44:29 +1000 Lex Trotman elextr@gmail.com wrote:
SVN version should now only save config files when needed. I now vaguely remember knowing about the problem, certainly I had made the function that reads the build commands dialog return a bool true if anything changed.
But I did nothing with it (TODO list failure?), so now its used.
Great, thanks :)
Regards, Nick