[Geany-devel] compiling a C/C++ header (Re: C/C++ Header filetypes)

Lex Trotman elextr at xxxxx
Fri Nov 21 02:20:21 UTC 2008


2008/11/20 Nick Treleaven <nick.treleaven at btinternet.com>

> On Tue, 18 Nov 2008 21:53:47 +1100
> "Lex Trotman" <elextr at gmail.com> wrote:
>
> > I am confused about what we each mean when we are talking about
> > 'build' here, and looking back I am not sure I have been consistent
> > in my usage either.  So I suggest the terminology for this discussion:
> >
> > 1. Filetype commands, menu items labelled:
> >  - compile,
> >  - build which I suggest we call build(link) to distinguish it from
> > other meanings of build and
> >  - execute.
>
> OK, I'll try to do this.
>
> > Although having header compile as an extra filetype command can work,
> > the build(link) menu item can do funny things if invoked on header
> > files.  This is probably fine for an expert like Nick but could be an
> > issue for a beginner just trying things out, thats why I don't like
> > having commands that are not useful available to users.
>
> OK, so this is another reason why compiling headers with an extra
> command is not ideal. The other reason is that it's less natural to use
> a different command.
>
> I will try to look at your build command variants code sometime.


Ok, remember that there is still the quick and dirty option of testing for
headers explicitly.  I was trying to avoid it, but, if the test is in place
of the call to the new get_variant function (or whatever I called it, I
don't have the code with me) and the result is stored in the document as I
did with the variant, then the test only has to exist in one place and can
be clearly commented.

>
>
> > > >My thoughts are that for a compile header command, this can be an
> > > >_extra_ build command, so not losing compile, build, etc. As I
> > > >originally said, ideally we wouldn't limit how many commands the
> > > >user can run, it's up to them.
> > >
> >
> > I agree that the ultimate would be to have unlimited commands, but
> > that makes for a more complex configuration GUI and
> > configuration/preference/project file format.  My proposal for now is
> > to add one extra filetype command (compile, build(link), execute and
> > spare) and one extra make command (make all, make custom, make
> > object, execute and spare), remembering all labels and commands can
> > be configured..
>
> Yes, this is fine to implement a fixed number of commands now. In
> future we may extend this to be unlimited. But don't worry about this.
>
> > > >So, _if_ compiling a header is a generic command for a filetype,
> > > >have an extra build command configured for the C++ filetype (and C
> > > >if you want).
> >
> > As I said above I am confused about where you are suggesting this
> > command to be added, as a filetype command or as a make command?
>
> Either a filetype or a project command, depending on how the user wants
> to compile headers. It sounds like you would want a filetype command to
> do this, so it was only available for C documents;


That is where I'd like to put the default header compile command, there is
no reason not to have the ability on make commands as well if the makefile
supports it.

> I would want a
> project command probably because I use libraries that use pkg-config
> for include file paths.
>

Yes of course, I try if at all possible not to pull such things into header
files which means that I don't need any extra includes and then it is  not
imported into all files that use the header.  I try to keep these things in
implementation specific parts, but of course it is not always possible.

>
> We can't use a make command because we don't know what the precompiled
> header (PCH) extension is. Although that could be configurable like
> 'Make Object', maybe it wouldn't be so useful because people might
> not want to have to add PCH targets to all their makefiles.


And it isn't portable see below.

>
> > Compiling headers as a project make command would be great, but I
> > don't know how to set up make and other builders to compile headers
> > (remember that the original reason for my build commands changes was
> > to support different builders)  If there is no output file, what
> > prevents make compiling all the headers every time?  Gcc leaves
> > a .gch file but not all compilers do that (eg Intel C++ for Linux).
>
> OK, out of interest, how do they record the compiled header output? In
> a single cache file? If there's a file somewhere, you can write
> makefile targets that depend on header file changes. But as I said,
> maybe people don't want to have to add PCH makefile targets anyway,
> even if it's possible.
>

A quick straw poll among users of other compilers gave:

1. Some compilers ignore header files listed on the command line.
2. Compilers that don't do pre-compiled headers output nothing, a degenerate
.o or .obj file (or as set by -o option) for compiling a header file.
3. Compilers that do pre-compiled headers seem to have compiler specific
extensions.  Probably good since they are unlikely to have the same internal
format.  Nobody we know uses a single cache for C/C++ compilation results,
but it may happen in future.  Ada operates that way, although many compilers
still use separate files but in one directory.  Of course thats assuming
that you arn't using ccache or similar ;-)

All very non-portable I'm afraid

On unix we could always dump unwanted output files into /dev/null using -o
and touch a dummy file to indicate that re-compilation isn't needed, but
again not portable outside unix.  I don't know if autoconf, cmake or any of
the other configurators could help.

Cheers
Lex

>
> Regards,
> Nick
> _______________________________________________
> Geany-devel mailing list
> Geany-devel at uvena.de
> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geany.org/pipermail/devel/attachments/20081121/3b56f074/attachment-0002.html>


More information about the Devel mailing list