2008/11/20 Nick Treleaven
<nick.treleaven@btinternet.com>
On Tue, 18 Nov 2008 21:53:47 +1100
> 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