Re: [cmake-developers] [PATCH] Discussion needed: FindBISON: refine VERBOSE feature of BISON_TARGET

[Eon Jeong]

I wrote new patches for each of: changing usage of VERBOSE, new option
REPORT_FILE, and refactoring all of them.


0001-FindBISON-Change-usage-of-VERBOSE-file-to-VERBOSE-fi.patch
Description: Binary data


0002-FindBISON-Add-REPORT_FILE-option-to-pass-report-file.patch
Description: Binary data


0003-FindBISON-Refactor-public-and-inner-macro-routines.patch
Description: Binary data
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] [PATCH] Discussion needed: FindBISON: refine VERBOSE feature of BISON_TARGET

[Ben Boeckel]

On Fri, Jul 15, 2016 at 10:52:23 -0400, Brad King wrote:
> On 07/15/2016 10:45 AM, Eon Jeong wrote:
> > I considered that way, but doing this can't figure "VERBOSE" used
> > without  from never used. same empty string value.
> 
> You could hack it with something like
> 
>   if("${ARGN}" MATCHES ";VERBOSE;")
> 
> if the value comes back empty.

Avoiding regexes here would be better:

list(FIND ARGN "VERBOSE" has_verbose)

--Ben
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] [PATCH] Discussion needed: FindBISON: refine VERBOSE feature of BISON_TARGET

[Eon Jeong]

Thanks Brad, I'll try with that hack.

Eon
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] [PATCH] Discussion needed: FindBISON: refine VERBOSE feature of BISON_TARGET

[Brad King]

On 07/15/2016 10:45 AM, Eon Jeong wrote:
> I considered that way, but doing this can't figure "VERBOSE" used
> without  from never used. same empty string value.

You could hack it with something like

  if("${ARGN}" MATCHES ";VERBOSE;")

if the value comes back empty.

-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] [PATCH] Discussion needed: FindBISON: refine VERBOSE feature of BISON_TARGET

[Brad King]

On 07/15/2016 10:35 AM, Eon Jeong wrote:
> [VERBOSE []] was my hope, but it's not easy. Since FindBISON now
> uses CMakeParseArguments, a keyword can't be used both as an option
> and as a one-value keyword.

Just make it a multi-value keyword and then reject multiple values
manually after cmake_parse_arguments returns.

-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] [PATCH] Discussion needed: FindBISON: refine VERBOSE feature of BISON_TARGET

[Eon Jeong]

2016-07-15 23:38 GMT+09:00 Brad King :
> Just make it a multi-value keyword and then reject multiple values
> manually after cmake_parse_arguments returns.

I considered that way, but doing this can't figure "VERBOSE" used
without  from never used. same empty string value.

Eon
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Natvis support in Visual Studio

[Brad King]

On 07/15/2016 10:23 AM, Robert Dailey wrote:
> Nice, I wasn't aware that there was already a feature in place to
> support this. Given that this exists, is there any point to adding an
> explicit code change to support natvis files?

The VS_TOOL_OVERRIDE option is nice to allow projects a path forward
for types that CMake doesn't yet support.  However, we should still
add types as needed to CMake.

> I have a simple patch attached that shows the change I've made to the code.

Applied, thanks:

 VS: Add support for NATVIS files
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a6290cff

-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] [PATCH] Discussion needed: FindBISON: refine VERBOSE feature of BISON_TARGET

[Eon Jeong]

Thank you clarifying the basic rules.

2016-07-15 22:33 GMT+09:00 Brad King :
>> 3.5. [VERBOSE []] and [REPORT_FILE ]. In this case, 
>> argument of [VERBOSE ] can be either ignored or used (copying
>> the report file.) This does not break compatibility at all
>
> I think this is the best solution.  One could also reject use of
> both  options at the same time.

[VERBOSE []] was my hope, but it's not easy. Since FindBISON now
uses CMakeParseArguments, a keyword can't be used both as an option
and as a one-value keyword.

Possible solutions are:

- Splitting [VERBOSE ] into [VERBOSE] (just `--verbose`) and
[VERBOSE_FILE ] (`--verbose` and copy). It breaks the
compatibility slightly, but I think this is an approvable break even
without REPORT_FILE because there was no choice to get just
default-named output file. In this case, "VERBOSE", "VERBOSE
REPORT_FILE " or "VERBOSE_FILE " or any combinations can
be used.

- Let [VERBOSE ] and [REPORT_FILE ] independently exist.
[VERBOSE ] means `--verbose` and copying to , and
[REPORT_FILE ] means `--report-file ` *and `--verbose`*.
cf. In bison, `--report-file ` does not imply `--verbose`.

- Extending CMakeParseArguments so a one-value keyword can be also
used as options when it's passed both in  and
. Then combinations "VERBOSE", "VERBOSE ",
"VERBOSE REPORT_FILE ", "VERBOSE  REPORT_FILE " can
be used.

- Not using CMakeParseArguments.

Sorry for making mistake. I was thinking wrong about how
CMakeParseArguments works.

Thanks,

Eon
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Natvis support in Visual Studio

[Robert Dailey]

On Fri, Jul 15, 2016 at 9:05 AM, Brad King  wrote:
>  VS: Add a VS_TOOL_OVERRIDE source file property
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ed05f11d

Nice, I wasn't aware that there was already a feature in place to
support this. Given that this exists, is there any point to adding an
explicit code change to support natvis files?

I will install a 3.6.2 nightly build and try out that property. I like
that idea, the only downside is you lose the automatic mapping based
on file extension. I have a simple patch attached that shows the
change I've made to the code. I don't have time ATM to write a unit
test for it, but hopefully you can build onto this if you find it
valuable? Seems the change is simple based on your explanation.


0001-Support-NATVIS-files-in-VS10-generator.patch
Description: Binary data
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Natvis support in Visual Studio

[Brad King]

On 07/15/2016 09:47 AM, Robert Dailey wrote:
> is Kitware officially using github or gitlab? CMake exists on both

The GitLab repo is used as the issue tracker (recently migrated from Mantis).
The GitHub repo is offered as a convenience for the community but is not
the official path for contribution.  See CONTRIBUTING.rst for the documented
official contribution path.  GitLab MRs are also allowed but not documented
yet because we're still experimenting with them.

> mapped to object files and call WriteSource() on each of those.
> Currently it seems to support C, CXX, MASM, and RC language types.
> Then there is WriteExtraSources(), which I can only assume is
> "everything else". Is this correct?

Yes.  WriteSource() is for first-class language that use enable_language().
Those languages need to be supported by all generators so adding natvis to
it may not make sense.

> If I am correct, would I also be correct to assume that
> WriteExtraSource should be the one to set the XML element name
> () for *.natvis files based on LANGUAGE being set to NATVIS?

Yes.  It already has a table of VS-specific special cases checked by
file extension.  See also:

 VS: Add a VS_TOOL_OVERRIDE source file property
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ed05f11d

> To add to this confusion, cmVisualStudio7Generator::WriteGroup()

That is only for VS <= 9.

> Somewhere I need to be able to automatically set the LANGUAGE property
> based on file extension.

The LANGUAGE property is meant to be set by projects.  If it is not
set then we detect the language.  We don't need to explicitly set
the property based on the extension.  I think WriteExtraSource is
the only place that needs modification for this.

-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] [PATCH] ninja: Generalize check for sysconf(3) call.

[Brad King]

On 07/15/2016 06:46 AM, Raphael Kubo da Costa wrote:
> Commit f9644a2d ("cmGlobalNinjaGenerator: Clarify logic for forcing use
> of response files") started considering that negative command line
> length values meant forcing the use of response files.
> 
> cmNinjaNormalTargetGenerator::calculateCommandLineLength() was not
> implemented for certain operating systems

Thanks.  The problem you encountered is actually a regression in 3.6.0.
I've fixed it here:

 Ninja: Do not force response files when no sysconf(3) limit is used
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=86dd2427

and queued the change for merge to `release` for 3.6.1.

I've also applied your change on `master` for development toward 3.7:

 Ninja: Generalize check for sysconf(3) call
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5ec17e61

Thanks,
-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

[cmake-developers] Natvis support in Visual Studio

[Robert Dailey]

Hello CMake devs,

I'm writing code to support Natvis files in Visual Studio 2015
(earlier versions support this as well, I think).

I found an issue regarding this here (is Kitware officially using
github or gitlab? CMake exists on both):
https://gitlab.kitware.com/cmake/cmake/issues/16043

Corresponding link on mantis (deprecated?):
https://cmake.org/Bug/view.php?id=16043

I have some questions. It's not straightforward on  how to implement
this. In cmVisualStudio10TargetGenerator, there is a WriteAllSources()
function which seems to do 2 main things. It seems to look up things
mapped to object files and call WriteSource() on each of those.
Currently it seems to support C, CXX, MASM, and RC language types.
Then there is WriteExtraSources(), which I can only assume is
"everything else". Is this correct?

If I am correct, would I also be correct to assume that
WriteExtraSource should be the one to set the XML element name
() for *.natvis files based on LANGUAGE being set to NATVIS?
To add to this confusion, cmVisualStudio7Generator::WriteGroup() seems
to do the file extension to LANGUAGE mapping, and I can't tell if the
VS10 generator class is also sharing this code. If it is, do I extend
that function in the VS10 generator class for *.natvis files?
Somewhere I need to be able to automatically set the LANGUAGE property
based on file extension.

Guidance is appreciated!
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] [PATCH] Improve FindGIF version detection (fix for issue #16196)

[Brad King]

On 07/14/2016 06:31 PM, Ben Campbell wrote:
> new patch attached!

Thanks, looks good!  Applied and merged to `next` for testing:

 FindGIF: Detect version from GIF 4.1.6 and above
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0a6c227d

Once this is merged to `master` the issue should close automatically.

-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] [PATCH] Discussion needed: FindBISON: refine VERBOSE feature of BISON_TARGET

[Brad King]

On 07/15/2016 04:51 AM, Eon Jeong wrote:
> review past discussion on this issue.

Thanks for summarizing.

> 3.5. [VERBOSE []] and [REPORT_FILE ]. In this case, 
> argument of [VERBOSE ] can be either ignored or used (copying
> the report file.) This does not break compatibility at all

I think this is the best solution.  One could also reject use of
both  options at the same time.

> - Behavioral & syntactic compatibility of [VERBOSE ] between
> before and after the patch.

We need to remain compatible with users of [VERBOSE ].

> - If we add [REPORT_FILE ], it does not work on systems using
> bison before 2007. We may care it with custom command using `move`, or
> not.

If a project chooses to use REPORT_FILE then it is implying a dependency
on a sufficiently new version of bison, not CMake.  This is fine.

Thanks,
-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

[cmake-developers] [PATCH] ninja: Generalize check for sysconf(3) call.

[Raphael Kubo da Costa]

Commit f9644a2d ("cmGlobalNinjaGenerator: Clarify logic for forcing use
of response files") started considering that negative command line
length values meant forcing the use of response files.

cmNinjaNormalTargetGenerator::calculateCommandLineLength() was not
implemented for certain operating systems such as the BSDs despite the
fact that sysconf(_SC_ARG_MAX) also works there. This caused problems
when generating static libraries, as ar(1) on FreeBSD does not recognize
the @file argument syntax.

By generalizing the checks for whether to use sysconf(_SC_ARG_MAX) this
problem can be worked around and we avoid having to change the #ifdef
for each new operating system implementing sysconf(3) according to
POSIX.
---
 Source/cmNinjaNormalTargetGenerator.cxx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Source/cmNinjaNormalTargetGenerator.cxx 
b/Source/cmNinjaNormalTargetGenerator.cxx
index c34df3c..5e965ff 100644
--- a/Source/cmNinjaNormalTargetGenerator.cxx
+++ b/Source/cmNinjaNormalTargetGenerator.cxx
@@ -375,7 +375,7 @@ static int calculateCommandLineLengthLimit(int 
linkRuleLength)
 #ifdef _WIN32
 8000,
 #endif
-#if defined(__APPLE__) || defined(__HAIKU__) || defined(__linux)
+#if defined(_SC_ARG_MAX)
 // for instance ARG_MAX is 2096152 on Ubuntu or 262144 on Mac
 ((int)sysconf(_SC_ARG_MAX)) - 1000,
 #endif
-- 
2.9.0

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] [PATCH] Discussion needed: FindBISON: refine VERBOSE feature of BISON_TARGET

[Eon Jeong]

This mail is not bound to thread because of my mistake. The original
thread is [PATCH] Discussion needed: FindBISON: refine VERBOSE feature
of BISON_TARGET
.
Any review should be made on the thread.
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] [PATCH] Discussion needed: FindBISON: refine VERBOSE feature of BISON_TARGET

[Eon Jeong]

A year passed so long to reply for a personal reason.

Adding to this list because I think it's better to review past
discussion on this issue.

So let's clearify:

1. Current [VERBOSE ] defines `--verbose`, so bison generates
foo.output from foo.y, (generating also foo.tab.c and foo.tab.h) then
cmake copies foo.output to . It's intermediate-file-and-copy as
said. It's also problematic because using [VERBOSE ] forces the
report file to be copied to some other name.

2. Since 2007, bison has `--report-file ` option that specifies
the report file name instead of foo.output. so [REPORT_FILE ] is
suggested. No intermediate file is made; so using this breaks
behavioral backward compatibility. On the other hand, some build
systems are still using bison of version before 2007.

3. There are some candidates replacing current [VERBOSE ]:

3.1. No change for our FindBISON module. `--report-file ` option
can be used via COMPILE_FLAGS. Hint this in documentation.

3.2. [VERBOSE []]. This does not break backward compatibility,
and makes someone can choose the report file is copied or not.

3.4. Just [VERBOSE] and [REPORT_FILE ]. Independently, [VERBOSE]
inserts `--verbose`, [REPORT_FILE ] inserts `--report_file
`. No more intermediate-file-and-copy, so breaking
compatibility, but the clearest solution.

3.5. [VERBOSE []] and [REPORT_FILE ]. In this case, 
argument of [VERBOSE ] can be either ignored or used (copying
the report file.) This does not break compatibility at all, but it's
dirty when [REPORT_FILE ] is cared for lower versions of bison
using `cmake -E copy` because [VERBOSE ] does the exact thing.

And many other solutions possible.

4. Issues are:

- Behavioral & syntactic compatibility of [VERBOSE ] between
before and after the patch.

- If we remove  from [VERBOSE ] so it becomes [VERBOSE],
syntactic compatibility breaks.

- If we add [REPORT_FILE ], it does not work on systems using
bison before 2007. We may care it with custom command using `move`, or
not.

These issues are about how CMake cares about the modules'
compatibility and clearness, so I need some direction.

I will make appropriate patch for the result.

Thanks,

Eon

2015-06-25 0:29 GMT+09:00 Brad King :
> On 06/24/2015 11:13 AM, 정언 wrote:
>> The copying command should be run right after each execution of bison.
>
> Yes.
>
>> However, add_custom_command never guarantees a running order of
>> internal commands. The documentation says, the commands can run
>> parallel so never ever put commands with implicit dependencies.
>
> I'm not sure what text from the documentation you're referencing,
> but I think that is warning about listing one output in multiple
> independent targets, e.g.
>
>  add_custom_command(OUTPUT out.txt ...)
>  add_custom_target(tgt1 DEPENDS out.txt)
>  add_custom_target(tgt2 DEPENDS out.txt)
>
> That is not the case here.
>
>> Again, we have two custom commands as a result of passing `VERBOSE` to
>> bison_target(). One runs bison, and the other runs cp.
>
> We only need one add_custom_command call.  It can list both outputs
> and have two COMMAND arguments.  Something like (untested):
>
>   if(...)
> set(_maybe_copy_verbose_output ${BISON_TARGET_ARG_VERBOSE})
> set(_maybe_copy_verbose_command
>   COMMAND ${CMAKE_COMMAND} -E copy 
> ${BISON_TARGET_output_path}/${BISON_TARGET_output_name}.output 
> ${BISON_TARGET_ARG_VERBOSE}
>   )
>   endif()
>
>   add_custom_command(OUTPUT ${BISON_TARGET_outputs} 
> ${_maybe_copy_verbose_output}
> ${BISON_TARGET_extraoutputs}
> COMMAND ${BISON_EXECUTABLE} ${BISON_TARGET_cmdopt} -o ${BisonOutput} 
> ${BisonInput}
> ${_maybe_copy_verbose_command}
> DEPENDS ${BisonInput}
> COMMENT "[BISON][${Name}] Building parser with bison ${BISON_VERSION}"
> WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR})
>
> When both COMMAND options are present they will run sequentially.
>
>> If VERBOSE behaved right, REPORT_FILE would not have any benefits over it.
>
> Wouldn't it be able to skip the intermediate file and copy step?
>
> -Brad
>



-- 
Eon Jeong 
Seoul, Rep. of Korea
Undergrad @ Dept.of Computer Science and Communication Engineering, Korea Univ.
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] [PATCH] Discussion needed: FindBISON: refine VERBOSE feature of BISON_TARGET

[Eon Jeong]

A year passed so long to reply for a personal reason.

Adding to this list because I think it's better to review past
discussion on this issue.

So let's clearify:

1. Current [VERBOSE ] defines `--verbose`, so bison generates
foo.output from foo.y, (generating also foo.tab.c and foo.tab.h) then
cmake copies foo.output to . It's intermediate-file-and-copy as
said. It's also problematic because using [VERBOSE ] forces the
report file to be copied to some other name.

2. Since 2007, bison has `--report-file ` option that specifies
the report file name instead of foo.output. so [REPORT_FILE ] is
suggested. No intermediate file is made; so using this breaks
behavioral backward compatibility. On the other hand, some build
systems are still using bison of version before 2007.

3. There are some candidates replacing current [VERBOSE ]:

3.1. No change for our FindBISON module. `--report-file ` option
can be used via COMPILE_FLAGS. Hint this in documentation.

3.2. [VERBOSE []]. This does not break backward compatibility,
and makes someone can choose the report file is copied or not.

3.4. Just [VERBOSE] and [REPORT_FILE ]. Independently, [VERBOSE]
inserts `--verbose`, [REPORT_FILE ] inserts `--report_file
`. No more intermediate-file-and-copy, so breaking
compatibility, but the clearest solution.

3.5. [VERBOSE []] and [REPORT_FILE ]. In this case, 
argument of [VERBOSE ] can be either ignored or used (copying
the report file.) This does not break compatibility at all, but it's
dirty when [REPORT_FILE ] is cared for lower versions of bison
using `cmake -E copy` because [VERBOSE ] does the exact thing.

And many other solutions possible.

4. Issues are:

- Behavioral & syntactic compatibility of [VERBOSE ] between
before and after the patch.

- If we remove  from [VERBOSE ] so it becomes [VERBOSE],
syntactic compatibility breaks.

- If we add [REPORT_FILE ], it does not work on systems using
bison before 2007. We may care it with custom command using `move`, or
not.

These issues are about how CMake cares about the modules'
compatibility and clearness, so I need some direction.

I will make appropriate patch for the result.

Thanks,

Eon

2016-07-15 17:42 GMT+09:00 Eon Jeong :
> Sorry, resending on list.
>
> 2016-07-15 17:42 GMT+09:00 Eon Jeong :
>> A year passed so long to reply for a personal reason.
>>
>> Adding to this list because I think it's better to review past
>> discussion on this issue.
>>
>> So let's clearify:
>>
>> 1. Current [VERBOSE ] defines `--verbose`, so bison generates
>> foo.output from foo.y, (generating also foo.tab.c and foo.tab.h) then
>> cmake copies foo.output to . It's intermediate-file-and-copy as
>> said. It's also problematic because using [VERBOSE ] forces the
>> report file to be copied to some other name.
>>
>> 2. Since 2007, bison has `--report-file ` option that specifies
>> the report file name instead of foo.output. so [REPORT_FILE ] is
>> suggested. No intermediate file is made; so using this breaks
>> behavioral backward compatibility. On the other hand, some build
>> systems are still using bison of version before 2007.
>>
>> 3. There are some candidates replacing current [VERBOSE ]:
>>
>> 3.1. No change for our FindBISON module. `--report-file ` option
>> can be used via COMPILE_FLAGS. Hint this in documentation.
>>
>> 3.2. [VERBOSE []]. This does not break backward compatibility,
>> and makes someone can choose the report file is copied or not.
>>
>> 3.4. Just [VERBOSE] and [REPORT_FILE ]. Independently, [VERBOSE]
>> inserts `--verbose`, [REPORT_FILE ] inserts `--report_file
>> `. No more intermediate-file-and-copy, so breaking
>> compatibility, but the clearest solution.
>>
>> 3.5. [VERBOSE []] and [REPORT_FILE ]. In this case, 
>> argument of [VERBOSE ] can be either ignored or used (copying
>> the report file.) This does not break compatibility at all, but it's
>> dirty when [REPORT_FILE ] is cared for lower versions of bison
>> using `cmake -E copy` because [VERBOSE ] does the exact thing.
>>
>> And many other solutions possible.
>>
>> 4. Issues are:
>>
>> - Behavioral & syntactic compatibility of [VERBOSE ] between
>> before and after the patch.
>>
>> - If we remove  from [VERBOSE ] so it becomes [VERBOSE],
>> syntactic compatibility breaks.
>>
>> - If we add [REPORT_FILE ], it does not work on systems using
>> bison before 2007. We may care it with custom command using `move`, or
>> not.
>>
>> These issues are about how CMake cares about the modules'
>> compatibility and clearness, so I need some direction.
>>
>> I will make appropriate patch for the result.
>>
>> Thanks,
>>
>> Eon
>>
>> 2015-06-25 0:29 GMT+09:00 Brad King :
>>> On 06/24/2015 11:13 AM, 정언 wrote:
 The copying command should be run right after each execution of bison.
>>>
>>> Yes.
>>>
 However, add_custom_command never guarantees a running order of
 internal commands. The documentation says, the commands can run
 parallel so never ever put commands with implicit dependencies.
>>>
>>>