Build fails with: Cannot open include file: 'src/flex-scanner.h' about winflexbison HOT 21 CLOSED

These lines just #line directives. They don't affect compilation, just redirect errors locations if any.
These lines are from original bison source code.

Try to replace "/Users/akim/src/gnu/bison" with "../.." in scan-gram.c file to revert #line directives to previous format and check if it helps you.

In case of success let me know and will modify the code.

from winflexbison.

You are right. It has nothing to do with these hard coded paths and even when I search&replace them the error remains.

There is some kind of including problem for src/flex-scanner.h

I can reproduce this locally with my VS2017 setup and in the CI in various configuration.

I'm trying to package winflexbison for Conan right now, however, for this issue it should be only relevant to know that the Conan recipe is executing CMake, which means a plain CMake build should get the same results.

Visual Studio 2013 fails in both versions 2.5.14 and 2.5.15, but VS2015 und VS2017 succeeded in 2.5.14

The error:
https://ci.appveyor.com/project/Croydon/conan-winflexbison/build/job/ktab507hk5wrxb3i#L710

All 2.5.15 results: https://ci.appveyor.com/project/Croydon/conan-winflexbison/build/1.0.6
All 2.5.14 results: https://ci.appveyor.com/project/Croydon/conan-winflexbison/build/1.0.1

Update/Edit: I just executed a plain CMake build and can confirm that the same errors happens.

from winflexbison.

this was may patch, tested, working:

diff --git a/bison/CMakeLists.txt b/bison/CMakeLists.txt
index 02fad2c..05e3ee8 100644
--- a/bison/CMakeLists.txt
+++ b/bison/CMakeLists.txt
@@ -18,5 +18,6 @@ add_executable(${PROJECT_NAME}
 )
 
 target_include_directories(${PROJECT_NAME} PRIVATE "src")
+target_include_directories(${PROJECT_NAME} PRIVATE "${CMAKE_CURRENT_SOURCE_DIR}")
 
 target_link_libraries(${PROJECT_NAME} common_lib kernel32.lib user32.lib)

from winflexbison.

I've checked CMake building of winflexbison and can confirm problems with include paths there.
The solution from @guruofquality fixed these issues for me. And I've added patch to the master.

@Croydon please check if this patch resolved your problem with Conan packaging.

from winflexbison.

With this patch applied VS2015 and 2017 are fine now.

VS2013 is still failing. Would you mind having a look? https://ci.appveyor.com/project/Croydon/conan-winflexbison/build/1.0.8

E.g. https://ci.appveyor.com/project/Croydon/conan-winflexbison/build/1.0.8/job/v4klqttnu8tkpqhw#L766

from winflexbison.

Do you need VS2013 working?
I only have VS2017 installed and focused on this version stability/correctness.

from winflexbison.

As I see there are different errors:
error LNK2001: unresolved external symbol _snprintf

Probably some breaking changes vs2013 vs vs2015.

from winflexbison.

There are a multitude of breaking changes between VS2013 and VS2015 - VS2015 at least partially implemented C99, which is the reason why it is good to test compilation with VS2013 compiler set and the newest one.

You can install both variants and just set a different compilation toolset (see Move to Visual Studio 2017 without upgrading your toolset). Note: If you install an older version after a new version you may have to run repair on the newer one afterwards.

from winflexbison.

When we are packaging for Conan then we are trying to get it going for all compiler versions and major configurations starting at Visual Studio 2013, GCC 4.9, Clang 3.9 and Apple Clang 7.3, excluding everything which isn't supported official by the upstream project.

So if you are saying that Visual Studio 2013 isn't official supported by Winflexbison, then this is fine by me personally. However, in this case this should probably be noted somewhere and the VS2010 and VS2013 directories should get deleted.

I figured out the problem for VS2013 and have written a patch, which you can find here: https://github.com/Croydon/conan-winflexbison/blob/bec13269bf94165588036d1257a1c01a633ac10c/0002-workaround-for-visual-studio-2013.patch

As another side note supporting VS2013 would be nice for some consumers of winflexbison. I'm packaging winflexbison right now with the intention to consume it when packaging doxygen, which is supporting VS2013. (winflexbison is a build dependency of doxygen)

from winflexbison.

Thank you for the patch. I've up-streamed it to the winflexbison. Please check.

Let's stay with VS2013 as a minimal supported version.
Anyway I can test new changes with VS2017 only. Anyone greatly welcome to pull-request/patch any issues related with older versions of VS. Any help appreciated.
Or at least just open issue here like this one, and I will try to fix the problem.

PS I'm planning to migrate win_bison to version 3.1 some day (see issue). So we can expect some new problems that time.

from winflexbison.

Master seems to build just fine without any additional patches.

Thanks for your work!

from winflexbison.

Note: master currently doesn't compile with VS2010:

• flex: missing include directory $(ProjectDir)..\misc, as soon as this is added: everything works
• bison:
  • missing include directory $(ProjectDir).. [fixes the original reported issue]
  • definition of variables in the mid of a block - could be fixed by either moving the declaration to the start of the block or by starting a new block before definition

If VS2010 works without any big issues I'd prefer to keep it in...

from winflexbison.

@GitMensch Do you have a specific environment where you need to build winflexbison from source and can't update to a newer version of Visual Studio?

Also building it via CMake should still work if it works at all. It should even fix all of these include problems.

from winflexbison.

definition of variables in the mid of a block - could be fixed by either moving the declaration to the start of the block or by starting a new block before definition

I'm trying to minimize code modifications to simplify adopting new versions.
I think original maintainers of flex/bison went forward and dropped support of such old C compiler standards that used in VS2010.

If there is no significant reason to keep VS2010 lets drop it too.
Your thoughts @GitMensch ?

from winflexbison.

Do you have a specific environment where you need to build winflexbison from source and can't update to a newer version of Visual Studio?

If you develop and need a fix for a not-yet-released version it is always good to be able to compile "with whatever is available on the machine".

Also building it via CMake should still work if it works at all. It should even fix all of these include problems.

I try to not use CMake if it isn't necessary. It is an additional dependency "just to build the program".

lexxmark agreed to include CMake but keeping the project files to allow for both options.

@lexxmark: All current Project Files don't work (include directories wrong, therefore I reopen this).
I offer to fix this and would use the same layout that is used in VC2010 (without sub-directories per project) for all versions. What do you think?
Afterwards I'll merge #23 (including deletion of the VS2010 folder).

from winflexbison.

I try to not use CMake if it isn't necessary. It is an additional dependency "just to build the program".

I see where this is coming from, however, CMake is a really lightweight dependency which is widespread adopted. The upstream flex project will soon have CMake support as well westes/flex#322

But even if you want to keep the VS project folders in there, "someone" could just keep generating them via CMake and push the generated files. No need to manually maintain x-times the same thing in different forms, right?

from winflexbison.

But even if you want to keep the VS project folders in there, "someone" could just keep generating them via CMake and push the generated files. No need to manually maintain x-times the same thing in different forms, right?

The last time I've checked this didn't worked out - CMake created solutions that were broken after moving the root folder. Is this fixed?

If yes: along with adding "binary" artifacts to Appveyor that contain the "release" version an artifact that contains the "source" version could be added which includes the solutions created by CMake (maybe post-processed if necessary).

@Croydon Can you please give this a try? If this works out I'd actually prefer remove the VS files.

Note: flex is not compatible to VS (or most other win32 compilers), see westes/flex#367 therefore this doesn't count :-)

from winflexbison.

All current Project Files don't work (include directories wrong, therefore I reopen this).

I could only check VS2017 solution and it's successfully built now (both Release/Debug).

I offer to fix this and would use the same layout that is used in VC2010 (without sub-directories per project) for all versions. What do you think?

If you prefer to change folders layout in VSXXX folders you can do it. I don't have any preference here.
If you can, please check 2013/2015 solutions/projects.

Afterwards I'll merge #23 (including deletion of the VS2010 folder).

Good

from winflexbison.

@Croydon Can you please give this a try? If this works out I'd actually prefer remove the VS files.

To be honest I don't want to spend time on this as I'm thinking the best solution is simply to use CMake in all cases and remove the VS project files from the repository altogether.
I don't understand your negative attitude towards using CMake.

Note: flex is not compatible to VS (or most other win32 compilers), see westes/flex#367 therefore this doesn't count :-)

I used this as one example of the widespread adoption of CMake, so it is a valid example

from winflexbison.

Hm, I'll try to check if the CMake generated files as-is are useful to actually use them within VS and if they have any issues when the project root is moved.

@Croydon If the results are reasonable I'll come back asking you to add another "source" artifact containing these [and delete the current ones from the repo]. Are you OK with that?

from winflexbison.

Sorry, this apparently didn't get my attention back then

@GitMensch I'm still of the opinion that maintaining 3+ different Visual Studio project solutions files next to a saner solution like CMake is pointless. So personally I don't want to spend time engineering a custom solution for this.

Visual Studio 2019 even has a pretty solid CMake integration (and is constantly getting even further integrated in Microsoft tools in general). So you don't even need to leave VS or install anything manually next to it.

As far as I can see all problems in this issues are solved. If the Visual Studio project files are still of concern I think it would be better to create a new issue to keep the discussion focused

from winflexbison.