Author Topic: Make file extensions to be freely defined  (Read 7678 times)

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Make file extensions to be freely defined
« on: August 20, 2005, 10:31:35 am »
Setting up (new) compilers is greatly modularised ind Code::Blocks. So should be for the file-extension.

This would enable two improvements:
1.) Imagine someone would like to use ".c++" and ".h++" extension for his files. Currently he's a bit lost since some operations apply to the default extensions only (e.g. saving settings "Link file" and "Compile file" in file properties).
2.) Attaching other (non-C++ domain) compilers would be fully enabled, e.g. the GNU Fortran (g77) or Java compilers.

To sum up: Why not making extensions be generally freely defined? Maybe one could use the lexers (there are the extensions provided anyway) for this...?!

I would like to hear the thoughts of the main developers...?!

Morten.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Re: Make file extensions to be freely defined
« Reply #1 on: August 20, 2005, 11:03:08 am »
You 're right. You see, C::B evolved much faster than I would expect it to and now we 're trying to catch up :)

I don't think it should be done using the lexers. We shouldn't mix the editor and compiler configuration like this.
What we could do is have a different configuration file, parsed at the beginning, specifying the file types.
E.g.:

Code
<FileTypes>
<File type="ftSource"
  name="C source"
  ext="*.c"
  compile="1"
  link="1"
  compiler="CC">
<File type="ftHeader"
  name="C header"
  ext="*.h"
  compile="0"
  link="0"
  compiler="CC">
<File type="ftSource"
  name="C++ source"
  ext="*.cc,*.cpp.*.c++,*.cxx"
  compile="1"
  link="1"
  compiler="CPP">
<File type="ftHeader"
  name="C++ header"
  ext="*.hh,*.hpp.*.h++,*.hxx"
  compile="0"
  link="0"
  compiler="CPP">
</FileTypes>

This way, C::B could be extended to understand more about a file by editing this config file.
What do you think?

Yiannis.
Be patient!
This bug will be fixed soon...

Offline Urxae

  • Regular
  • ***
  • Posts: 376
Re: Make file extensions to be freely defined
« Reply #2 on: August 20, 2005, 11:19:58 am »
I think it would be a lot nicer if this information was kept in C::B's settings, and you could edit it somewhere in the settings menu. That would be a logical place for it, wouldn't it? It would also be much more user-friendly than an extra configuration file.

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Re: Make file extensions to be freely defined
« Reply #3 on: August 20, 2005, 11:54:03 am »
I think it would be a lot nicer if this information was kept in C::B's settings, and you could edit it somewhere in the settings menu. That would be a logical place for it, wouldn't it? It would also be much more user-friendly than an extra configuration file.

Good point. But how many users will ever use (or even understand) the dialog you 're proposing?

The way I see it, config dialogs are for settings that people change (usually often). This kind of configuration is one-shot. And if someone has different needs can still edit one file. And if it extends C::B (like the fortran support that Morten is trying to add) the changes will be included in the C::B dist.
The point here is to avoid hardcoding values in C::B. You can think of it as a first step.
Don't forget: that's how lexers are done. XML config files which are written to registry on modification (and the registry has precedence over the XML - whether that's good is another thing altogether ;) ).

Thanks for the comments :)

Yiannis.
Be patient!
This bug will be fixed soon...

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: Make file extensions to be freely defined
« Reply #4 on: August 20, 2005, 01:28:52 pm »
I think both suggestions (mandrav's and Urxae's) don't exclude each other. Both sound good to me. I think there is an ongoing discussion in another thread about where and how to store the configuration. If a decision was made to store everything in XML files (which IMHO is a good option) both is possible. GUI's for such settings could be nicely done as plug-ins for those who would like to have buttons for configuration (why not?!). Using the registry is just so "Windows-like". Meanwhile I have a 50MB registry but as mandrav said: That's another story.

You see, C::B evolved much faster than I would expect it to and now we 're trying to catch up :)
Looks like the typical developer's dilemma...  :? - especially if a software envolves as Code::Blocks does. Seems as if you guys hit the nail on the head with Code::Blocks. I myself searched a lot for a good cross-platform IDE. Visual SlickEdit (www.slickedit.com) came close but it's not free. Code::Blocks is even better in certain areas and I think a lot of people were just waiting for it.

Morten.
« Last Edit: August 20, 2005, 01:43:00 pm by MortenMacFly »
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline rickg22

  • Lives here!
  • ****
  • Posts: 2283
Re: Make file extensions to be freely defined
« Reply #5 on: August 21, 2005, 05:40:25 pm »
Yes, I vote for the XML filetypes!

After all later we can add some config dialog that reads and edits the XML, right?

terje_a

  • Guest
Re: Make file extensions to be freely defined
« Reply #6 on: September 20, 2005, 12:48:57 am »
For what it's worth from a newbie...

I like the xml approach as well from a flexibility standpoint - allowing for adding support for any current and future compiler.  It may make the code a bit more complicated to develop but will have significant payoff in the long run by removing potential variables from source code and thereby eliminating the need to recompile code to account for changes in or entirely new compilers.

I am also interested in the fortran support and will gladly test anyone's efforts to support g77 through C::B...

I am not at this point comfortable enough with my programming skills to offer coding assistance, but I will gladly help with testing and documenting the fortran support and plugin for g77 options if you need such assistance.

I am currently working MS Windows, but am expecting to have my new Linux box up and running before the end of the calendar year.

I've seen many favorable comments about C::B and I am very impressed with what I've seen so far. 

I hope I can contribute to it's future success.  [...one tiny step at a time...]

regards,

terje