I have used this tool: https://github.com/etiennestuder/gradle-jooq-plugin
from jOOQ's official website to generate code from my database.
Yet if I set
directory = 'src/main/java'
when I run "gradle build", I get all these compile errors like:
database/information_schema/InformationSchema.java:218: error: no suitable constructor found for SchemaImpl(String,<null>)
super("INFORMATION_SCHEMA", null);
^
constructor SchemaImpl.SchemaImpl(Name) is not applicable
(actual and formal argument lists differ in length)
constructor SchemaImpl.SchemaImpl(String) is not applicable
(actual and formal argument lists differ in length)
Any fix for this?
Note that I wanted to put the generated code into the src folder because I want to use them in my code. I've heard to put them in the target or build folder instead, but I'm not sure how do you access those classes from target or build folder?
Thanks!
I was on 3.7. Now I switch to 3.9, everything turns out to be fine...
I've written a short blog post about this. Starting with jOOQ 3.16 and #12601, there's an additional compilation error in case users use:
An older version of org.jooq:jooq (the runtime library)
A newer version of org.jooq:jooq-codegen (the code generation library)
In general, the runtime library version >= codegen library version. The new compilation error might look like this:
[ERROR] …/DefaultCatalog.java:[53,73] cannot find symbol
[ERROR] symbol: variable VERSION_3_17
[ERROR] location: class org.jooq.Constants
Related
I'm trying to write a desktop program using an elm frontend with haskell backend.
To make writing the backend code idiomatically similar to the front end code (and make sending data between them easier), it would be great to use No Red Ink's custom prelude.
Stack is my build tool.
It's the first time I've tried to use a custom prelude. I can't get it to even turn up. The key unresolvable error message for me is the one with no suggested "different approaches to resolving this":
In the dependencies for nri-prelude-0.6.0.6:
unix is a library dependency, but the package provides no library`
Here's everything I tried:
I tried adding -fplugin=NriPrelude.Plugin to my ghc options in my stack.yaml but it said
<command line>: Could not find module `NriPrelude.Plugin'
So I tried adding nri-prelude to my dependencies, resulting in a recommendation to add
- nri-prelude-0.6.0.6#sha256:4ccc7488149a0401a9241c9b64db22c48a8639afaae11cffb263da5226e8acde,5289
to my stack.yaml, which resulted in a recommendation to add
- terminfo-0.4.1.5#sha256:4d1790aeb354797955ca1cb67035ca80f66a0d9cc4e43a51c1c9d566e00ce350,1713
- unix-2.7.3#sha256:20079c504d0ca33fbf11de3a215d25220c8d43499a93049a8f2791323f3bd57b,6047
as well. This was a dead end for me because I got the error message:
Error: While constructing the build plan, the following exceptions were encountered:
In the dependencies for nri-prelude-0.6.0.6:
unix is a library dependency, but the package provides no library
needed due to Experiment-0.1.0.0 -> nri-prelude-0.6.0.6
Some different approaches to resolving this:
Plan construction failed.
I couldn't help but notice the empty list of approaches to resolving it this time.
Instead of going down that route I tried using a route that had worked for another library, by putting
- github: NoRedInk/haskell-libraries
commit: a202da122192ad2b9435f92086f5b4c5e304531b
in my stack.yaml. It didn't like that:
No cabal file found for Archive from https://github.com/NoRedInk/haskell-libraries/archive/a202da122192ad2b9435f92086f5b4c5e304531b.tar.gz
and when I tried
- github: NoRedInk/haskell-libraries/nri-prelude
commit: 8657ef0ea153a12fcaa0d048be98598512fe9df6
that didn't even parse:
Could not parse 'stack.yaml':
Aeson exception:
Error in $['extra-deps'][3]: failed to parse field 'extra-deps': parsing Text failed, expected String, but encountered Object
See http://docs.haskellstack.org/en/stable/yaml_configuration/
Apparently anything GUI-related in terms of components involves XML. I cannot go around actually configuring and building wxWidgets from source because of that. I'm new to wxWidgets.
My current setup is on Win10 with MSVC v141 (Visual Studio 2017) with the latest CMake version (currently 3.21).
Inside the config.cmake of the wxWidgets projects (using latest master branch) I see
wx_get_dependencies(EXTRALIBS_XML xml)
I am also calling CMake with -DwxUSE_XML=ON (among other parameters) but this still leads to:
the XML dependency is nowhere to be found
respectively it's not built
Linking then fails with the following error:
LINK : fatal error LNK1104: cannot open file 'wxxml.lib' [C:\Users\...\CMakeBuilds\ef5b5ada-ee42-7735-988a-ae37c735ccff\build\deps\build\wxwidgets\libs\qa\wxqa.vcxproj]
What library is actually wxWidgets using and how do I trigger it's retrieval and accordingly configuration and building? Since I am adding wxWidgets to my CMake project as an ExternalProject component, I would appreciated something in that line of thought. However any kind of information regarding this issue is more than welcome especially since it will shine light on how to configure other features (if I want them in the future) such as WebView.
The wxxml.lib issue is fixed now. While fixing it I also discovered a bug (of sort) in the build system of wxWidgets.
The reason why it failed to build this library in particular was actually quite simple but due to the lack of knowledge in the dependencies of wxWidgets. I thought that wxWidgets, given it depends on XML so much, has its own XML parser. Well, not really. The wxXML component actually uses and underlying 3rd party dependency called EXPAT, which - as you can see in my question - I have deactivated since it was giving me issues during the build (due to the still present problem of not being able to automatically retrieve dependencies).
What I did was to clone the libexpat repository, add it as an ExternalProject, set the variables for the libraries and include directory and pass them onto my wxWidgets project. But there is a catch...
The expat.cmake file looks as follows:
#############################################################################
# Name: build/cmake/lib/expat.cmake
# Purpose: Use external or internal expat lib
# Author: Tobias Taschner
# Created: 2016-09-21
# Copyright: (c) 2016 wxWidgets development team
# Licence: wxWindows licence
#############################################################################
if(wxUSE_EXPAT STREQUAL "builtin")
# TODO: implement building expat via its CMake file, using
# add_subdirectory or ExternalProject_Add
wx_add_builtin_library(wxexpat
src/expat/expat/lib/xmlparse.c
src/expat/expat/lib/xmlrole.c
src/expat/expat/lib/xmltok.c
)
set(EXPAT_LIBRARIES wxexpat)
set(EXPAT_INCLUDE_DIRS ${wxSOURCE_DIR}/src/expat/expat/lib)
elseif(wxUSE_EXPAT)
find_package(EXPAT REQUIRED)
endif()
I would use the *.cmake files of the 3rd party dependencies stored inside <ROOT_OF_WXWIDGETS_PROJECT>/build/cmake/lib to determine which variables I need to set if builtin is selected as the value for the respective library. Since I want to use my own I need sys (e.g. -DwxUSE_EXPAT=sys as a CMAKE_ARGS inside my wxWidgets ExternalProject) and also to pass the headers and libraries accordingly.
Given the file above one would assume that EXPAT_LIBRARIES is required. However after failing to build (yet again) and seeing that the reason was the activated expat build and that it was set as builtin I checked the log in detail and found the following error:
Could NOT find EXPAT (missing: EXPAT_LIBRARY) (found version "2.2.6")
Notice the EXPAT_LIBRARY. After passing it (-DEXPAT_LIBRARY=...) my build was complete. For me this is a bug or simply inconsistency between the dependency cmake file and the rest of the wxWidgets project.
It is important to note that I do not retrieve the external dependency through wxWidgets itself (see config.cmake and more precisely the macro wx_get_dependencies(...)). This solves the problem with a basic configuration and build of wxWidgets but if you don't want to tackle every dependency of wxWidgets on your own (why should you?), I recommend looking for a solution where the dependencies (at least the ones you don't want to deal with) are automatically retrieved, configured and build as builtin.
I am trying to build a custom modified version of the
MicroSIP softphone.
Before any modifications, I can't build the version 3.19.18 using VisualStudio 2017.
I am able to compile successfully the previous minor version: 3.18.5
The error is:
1>c:\users\xxxxxxxxx\microsip\maindlg.cpp(1038): error C2065: 'PJRPID_ACTIVITY_ON_THE_PHONE': undeclared identifier
If I look at the code that uses that identifier I come across this, that is new in 3.19:
case PJSUA_BUDDY_STATUS_ONLINE:
if (buddy_info.rpid.activity == PJRPID_ACTIVITY_ON_THE_PHONE) {
image = MSIP_CONTACT_ICON_ON_THE_PHONE;
if (PjToStr(&buddy_info.status_text).Left(4) == _T("Ring")) {
ringing = true;
If I look at the type of "buddy_info.rpid.activity" it's of type "pjrpid_activity" That is defined in "rpid.h" from the SIP library "pjsip" :
typedef enum pjrpid_activity
{
/** Activity is unknown. The activity would then be conceived
* in the "note" field.
*/
PJRPID_ACTIVITY_UNKNOWN,
/** The person is away */
PJRPID_ACTIVITY_AWAY,
/** The person is busy */
PJRPID_ACTIVITY_BUSY
} pjrpid_activity;
No 'PJRPID_ACTIVITY_ON_THE_PHONE' defined here. And that string can't be found anywhere else on that project.
This enum is part of the Open Source project pjsip which is currently on version 2.9.
I tried to look back into earlier versions to find out if that enum evolved and had the correct elements. No luck.
It looks like they are using a modified version of the pjsip library, but I can't find a link, a mention or anything that would help me to find out what is that missing dependency.
More than that, MicroSIP.org will charge you $95 to obtain a customized version including "source code and assistance with compilation if needed".
Of course it is needed if they keep secret the dependencies.
Anyway, MicroSIP is statically linked to the unknown pjsip library variant.
Microsip and PJSIP are both licensed under the GPLv2.
My question is: How to find out my missing dependency?
Are they required to disclose that information?
Does anyone know about a fork of pjsip that would be the one I am looking for?
Better, Has anyone been able to somehow compile MicroSIP, ver >= 3.19.0?
To build any distribution of Microsip, you should build pjsip first. Therefore you should set some source and library paths for the Microsip project. Then you can build cleanly. It may be that some library is missing like opus, etc... and you may need to find the current version of these and build them beforehand as well.
I came to see that you must be having different platform toolset for MicroSIP and PjProject. Try to build it from starting using the same build tool and platform toolset for the both of your project, it will automatically clear several issues.
I am trying to build an old version of an application which consists of VC++ projects that were written in Visual Studio 2003.
My OS is Windows 7 Enterprise (64-bit).
When I try and build the solution I get the following errors:
error C4772: #import referenced a type from a missing type library; '__missing_type__' used as a placeholder
fatal error C1084: Cannot read type library file: 'Smegui.tlb': Error loading type library/DLL.
They both complain about the following import statement:
#import "Smegui.tlb" no_implementation
This is not a case of the file path being incorrect as renaming the Smegui.tlb file causes the compiler to throw another error saying it cannot find the library.
Smegui is from another application that this one depends on. I thought perhaps I was missing a dll but there is no such thing as Smegui.dll.
All I know about .tlb files is that they are a type library and you can create them from an assembly using tlbexp.exe or regasm.exe (the later also registers the assembly with COM)
There is also an Apache Ant build script which uses a custom task to invoke devenv.com to build the projects. This is the same script that the build server originally used to build the application. It gives me the same errors when I try and run it.
The strangest thing about this is that I knew it ought to work seeing as it is all freshly checked out from subversion. I tried many different combinations of admin vs user elevation, VS vs Ant build, cleaning, release.
I have got it to build successfully about 5 times but the build seems to be non-deterministic.
If anyone can shed some light on how this tlb stuff even works or what this error might mean I would greatly appreciate it.
I found a far more reliable solution: open the tlb with oleview.exe and then close it.
Not sure what this actually does but it works every time.
I think oleview is actually one of the samples included with Visual Studio but I haven't had the time to debug it and see what it is doing.
I ran into this error because one type library was trying to load a dependent type library, which it could not find. Even though the dependent type library was in the same directory, and even though that directory was in the searchable path, the compiler would error loading the first type library, but not mention the dependent type library in the error.
To find the pseudo-missing type library, I ran Process Monitor (procman64.exe) during the compile. This showed that after the reported type library had successfully loaded, a dependent type library could not be found. It even showed all of the places that it was looking for the dependent type library, none of which were where it should have been looking (e.g.: ).
The fix was to add a <PreBuildEvent> to the project to copy the dependent .tlb file to one of the directories that was actually being searched.
<PreBuildEvent>
<Command>copy /Y ..\Lib\Interop\CWSpeechRecLib.tlb .\</Command>
</PreBuildEvent>
http://msdn.microsoft.com/en-us/library/sce74ah7%28VS.71%29.aspx
smegui.tlb is referencing some other tlb that the compiler can't find. If you have the .idl for smegui you might be able to figure out what the other is. I suspect the missing tlb is something that original build machine had registered but that your machine doesn't have registered.
A type library is a binary description of a set of interfaces, coclasses and enums. They're usually generated for COM components, in the case of tlbexp and regasm the tlb is created from the assembly metadata. For native COM components they are usually generated from an idl (Interface Description Language) file by the midl tool.
Edit:
I just noticed you're on x64 Windows. Are you building the project with a new version of Visual Studio? If so, are you targeting x86 or x64? If the latter, it may simply be a 32bit component that the compiler can't find (or less likely, a x64 component the x86 compiler can't find if you are targeting x86), for WOW64 the registry is virtualized for x86 vs. x64 applications.
Well I finally found out why I managed to get it to build sometimes and not others... sort of.
So long as I ran the build script with elevated administrator permissions and let that get as far as it could until that error occurred, then run the build script again as a protected administrator succeeded. Those steps must be done in that exact order with no other steps in between. If I try build in Visual Studio it does not work (although I did get it to succeed once). Probably some kind of virtualisation issue although it still doesn't quite make sense.
Well I don't need help on this any more and I know it's probably impossible to fully answer this question without knowing exactly what the build is doing. However if anyone does have any more thoughts I would happily receive them.
Cheers,
Steiny
I am trying to build an application which depends on Boost. So I downloaded Boost 1_41_0 to my Linux box and followed the instructions found on the Boost site for Unix variants,
http://www.boost.org/doc/libs/1_41_0/more/getting_started/unix-variants.html.
They basically suggest that I run ./bjam install, which I did. The build completed successfully. However, the library names don't seem to match the Boost naming convention described both in the documentation above, and what is specified in the makefile of the application I am trying to build.
I noticed that there are a bunch of options that I can specify to bjam and I tried to play with those, but no matter what happens I can't seem to get it quite right. My understanding is that the libraries should go into the $BOOST_ROOT/lib directory. This is where the libraries show up, but named:
libboost_thread.a
libboost_thread.so
libboost_thread.so.1.41.0
I'd expect them to be named libboost_thread-gcc41-mt-d-1_41_0 or something similar.
I did try ./bjam --build-type=complete --layout=tagged and I see:
libboost_thread.a
libboost_thread-mt.a
libboost_thread-mt-d.a
libboost_thread-mt-d.so
libboost_thread-mt-d.so.1.41.0
libboost_thread-mt-s.a
libboost_thread-mt-sd.a
libboost_thread-mt.so
libboost_thread-mt.so.1.41.0
libboost_thread.so
libboost_thread.so.1.41.0
So, I am not sure if I should just make stage my -L directory? Is there any documentation which describe this in more detail?
The names was changed in 1.40.0 - see in release notes:
Build System
The default naming of libraries in
Unix-like environment now matches
system conventions, and does not
include various decorations.
They probably forgot to update this part in the build documentation.
There are two variables here. First is "install" vs. "stage" (default). "install" copies both libraries and headers into a directory -- /usr/local by default, and you can then remove source tree. "stage" puts libraries to "stage/lib", and you should add "-L /stage/lib -I " flags.
Second is --layout=versioned and --layout=system. It seems like you have discovered what they do already, and indeed, system is default since 1.40. The getting started guide fails to mention this, and I've added an action item to update it. Ideally, you should talk to the authors of the application to use the system naming of boost libraries. If that's not possible, then building with --layout=versioned is the only option.
From the Boost documentation at http://www.boost.org/doc/libs/1_35_0/more/getting_started/windows.html#library-naming, the convention is:
-mt Threading tag: indicates that the library was built with multithreading support enabled. Libraries built without multithreading support can be identified by the absence of -mt.
-d ABI tag: encodes details that affect the library's interoperability with other compiled code. For each such feature, a single letter is added to the tag:
Key Use this library when:
s linking statically to the C++ standard library and compiler runtime support libraries.
g using debug versions of the standard and runtime support libraries.
y using a special debug build of Python.
d building a debug version of your code.
p using the STLPort standard library rather than the default one supplied with your compiler.
n using STLPort's deprecated “native iostreams” feature.
For example, if you build a debug version of your code for use with debug versions of the static runtime library and the STLPort standard library in “native iostreams” mode, the tag would be: -sgdpn. If none of the above apply, the ABI tag is ommitted.