I am a newbie to Creo toolkit. For trial purpose, I need to edit the location of the source and target folders in the default make-file available. A part of the make-file is given below for reference.
# File Name
MAKEFILENAME = make_install
# Machine Type
PRO_MACHINE_TYPE = x86e_win64
# Executable names
EXE = pt_inst_test.exe
EXE_DLL = pt_inst_test.dll
# Pro/Toolkit Source & Machine Loadpoint (EXTERNAL USE - DEFAULT)
PROTOOL_SRC = $(PROE_INSTALL_PATH)\protoolkit
PROTOOL_SYS = $(PROTOOL_SRC)/$(PRO_MACHINE_TYPE)
# Pro/Toolkit Source & Machine Loadpoint (PTC INTERNAL USE)
#PROTOOL_SRC = $(PTCSRC)/protoolkit
#PROTOOL_SYS = $(PTCSYS)
# Include File Paths
INCS = -I. -I$(PROTOOL_SRC)/protk_appls/includes -I$(PROTOOL_SRC)/includes
In the above given code, I need to replace the source (PROE_INSTALL _PATH) with the required folder location (For ex: C:\Users\sagarp\Desktop\trial) without editing the environment variable. Is it possible? If so, please help me with the basics of creating a make-file on my own.
I just started using Creo toolkit and saw this question.
It's an old question but I'd still post the answer.
You can update the
PROTOOL_SRC = $(PROE_INSTALL_PATH)\protoolkit
by giving relative path.
It could be current dir or whatever you prefer.
Example for current dir :
PROTOOL_SRC = .
PROTOOL_SYS = $(PROTOOL_SRC)/$(PRO_MACHINE_TYPE)
I am working on yocto, I want to compile some C files in yocto and install the resulting binary to external filesystem.
Before doing that I tried creating a separate reciepe and compile c code from it.
I am unable to compile it.
I am not sure to understand the question since it is not precise enough.
Including C files in recipe tree
If you want to have the C files in your recipe, having a file tree like this:
recipe-example/example/example_0.1.bb
recipe-example/example/example-0.1/helloworld.c
You can generate this example when you create a new layer using
yocto-layer <your-layer-name>
Your bb file will look like this:
#
# This file was derived from the 'Hello World!' example recipe in the
# Yocto Project Development Manual.
#
SUMMARY = "Simple helloworld application"
SECTION = "examples"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
SRC_URI = "file://helloworld.c"
S = "${WORKDIR}"
do_compile() {
${CC} helloworld.c -o helloworld
}
do_install() {
install -d ${D}${bindir}
install -m 0755 helloworld ${D}${bindir}
}
It will compile the hello world file and install it into /usr/bin on your image.
From a Git repo
You also can compile from a git repository, I advise you to read the manual and examples in your yocto folder. Here is an example here of wiringPi:
DESCRIPTION = "A library to control Raspberry Pi GPIO channels"
HOMEPAGE = "https://projects.drogon.net/raspberry-pi/wiringpi/"
SECTION = "devel/libs"
LICENSE = "LGPLv3+"
LIC_FILES_CHKSUM = "file://COPYING.LESSER;md5=e6a600fd5e1d9cbde2d983680233ad02"
# tag 2.29
SRCREV = "d79506694d7ba1c3da865d095238289d6175057d"
S = "${WORKDIR}/git"
SRC_URI = "git://git.drogon.net/wiringPi \
file://0001-Add-initial-cross-compile-support.patch \
file://0001-include-asm-ioctl.h-directly-for-_IOC_SIZEBITS.patch \
"
COMPATIBLE_MACHINE = "raspberrypi"
CFLAGS_prepend = "-I${S}/wiringPi -I${S}/devLib"
EXTRA_OEMAKE += "'INCLUDE_DIR=${D}${includedir}' 'LIB_DIR=${D}${libdir}'"
EXTRA_OEMAKE += "'DESTDIR=${D}/usr' 'PREFIX=""'"
do_compile() {
oe_runmake -C devLib
oe_runmake -C wiringPi
oe_runmake -C gpio 'LDFLAGS=${LDFLAGS} -L${S}/wiringPi -L${S}/devLib'
}
do_install() {
oe_runmake -C devLib install
oe_runmake -C wiringPi install
oe_runmake -C gpio install
}
It is fetching from a git repository, applying patches generated by git, using oe_runmake to compile with the makefiles.
With devtool
It has been asked in a comment on how to add a recipe with devtool.
We will still use wiringPi as an example again. Download it doing
https://github.com/WiringPi/WiringPi
The Makefile is is the folder wiringPi.
You can then do
devtool add <name_of_recipe> <path_to_Makefile_folder>
Take care of the warning from devtool
NOTE: Creating workspace layer in /home/dbensoussan/new_poky/poky/build/workspace
NOTE: Enabling workspace layer in bblayers.conf
NOTE: Using source tree as build directory since that would be the default for this recipe
NOTE: Recipe /home/dbensoussan/new_poky/poky/build/workspace/recipes/project/project.bb has been automatically created; further editing may be required to make it fully functional
This is generating the recipe as follow:
# Recipe created by recipetool
# This is the basis of a recipe and may need further editing in order to be fully functional.
# (Feel free to remove these comments when editing.)
#
# WARNING: the following LICENSE and LIC_FILES_CHKSUM values are best guesses - it is
# your responsibility to verify that the values are complete and correct.
LICENSE = "Unknown"
LIC_FILES_CHKSUM = "file://COPYING.LESSER;md5=e6a600fd5e1d9cbde2d983680233ad02"
# No information for SRC_URI yet (only an external source tree was specified)
SRC_URI = ""
# NOTE: this is a Makefile-only piece of software, so we cannot generate much of the
# recipe automatically - you will need to examine the Makefile yourself and ensure
# that the appropriate arguments are passed in.
do_configure () {
# Specify any needed configure commands here
:
}
do_compile () {
# You will almost certainly need to add additional arguments here
oe_runmake
}
do_install () {
# This is a guess; additional arguments may be required
oe_runmake install 'DESTDIR=${D}'
}
You can then edit your recipe to suit your configuration
With externalsrc
It is possible to use a directory present on the filesystem by using externalsrc.
I did not try it myself, nor have I the workspace ready to do, but #71GA in the comment tested the tutorial from the Koan software company https://wiki.koansoftware.com/index.php/Building_Software_from_an_External_Source and it worked. I will copy the content here:
in this case use the externalsrc class - you can inherit this in the original bb recipe or a bbappend:
inherit externalsrc
EXTERNALSRC = "/path/to/sources"
Depending on the type of build (eg, 'inherit module' for out of tree Linux kernel modules) you may or may not need to set EXTERNALSRC_BUILD.
inherit externalsrc
EXTERNALSRC = "/some/path"
EXTERNALSRC_BUILD = "/some/path"
If you're going to use it across a number of recipes you can inherit it globally at the configuration level (perhaps via an inc file that you include/require there):
INHERIT += "externalsrc"
EXTERNALSRC_pn-<recipename> = "/path/to/sources"
Recipe example using an external source for nInvaders package
#
# Recipe example with externalsrc
#
# (C)2019 Marco Cavallini - KOAN - <https://koansoftware.com>
#
LICENSE = "CLOSED"
LIC_FILES_CHKSUM = ""
inherit externalsrc
EXTERNALSRC = "/home/koan/yocto-qemuarm-sumo/ninvaders-0.1.1"
EXTERNALSRC_BUILD = "${EXTERNALSRC}"
DEPENDS = "ncurses"
EXTRA_OEMAKE = "-e"
do_install() {
install -d ${D}${bindir}
install -m 0755 nInvaders ${D}${bindir}
}
FILES_${PN} = "${bindir}/*"
You can just go to the official documentation to find your answer.
In the chapter 7.3 Writting a New Recipe of the yocto mega-manual, the very first example is exactly is what you need (Single .c File Package (Hello World!)).
I am trying to get Rsyslog's imfile plugin working without
any real success.
Here is useful OS version information:
# cat /etc/centos-release
CentOS Linux release 7.1.1503 (Core)
And here is Rsyslog version information:
# rsyslogd -v
rsyslogd 7.4.7, compiled with:
FEATURE_REGEXP: Yes
FEATURE_LARGEFILE: No
GSSAPI Kerberos 5 support: Yes
FEATURE_DEBUG (debug build, slow code): No
32bit Atomic operations supported: Yes
64bit Atomic operations supported: Yes
Runtime Instrumentation (slow code): No
uuid support: Yes
See http://www.rsyslog.com for more information.
I tried both legacy and RainerScript format of the configuration.
None of them works for me, sadly. I must be doing something completely wrong
but I simply can not decide on what it could be.
Here is my actual testing configuration (in RainerScript, the
former legacy version I tested was exactly the same in it's meaning):
# cat /etc/rsyslog.conf
global(
workDirectory = "/tmp"
)
module(
load = "imuxsock"
)
module(
load = "imjournal"
stateFile = "journal.state"
)
module(
load = "imfile"
pollingInterval = "10"
)
ruleset(name = "test-ruleset") {
if $syslogtag contains "test-syslogtag" then {
action(
type = "omfile"
file = "/tmp/test-file.log"
)
stop
}
}
input(
type = "imfile"
tag = "test-syslogtag"
stateFile = "test-input.state"
facility = "daemon"
severity = "debug"
file = "/tmp/test-input.in"
ruleset = "test-ruleset"
)
if prifilt("*.*") then {
action(
type = "omfile"
file = "/tmp/rsyslog-testing.log"
)
}
No warning nor error are produced by the Rsyslog with the above
configuration but also nothing from the /tmp/test-input.in file
is copied to the /tmp/test-file.log.
(I also double-checked the /var/log/audit/audit.log, of course, and ...
nothing suspicious is there. Being desperate on what's going on, I also
tried to setenforce 0 to switch SELinux off completely and to restart
the Rsyslog afterwards. It did not helped so the root cause of the problem
may not be SELinux-related issue.)
Also, the test-input.state file is correctly created in the global
workDirectory path (/tmp in this testing case). I also tried
standard paths (logs in /var/log, state file in /var/lib/rsyslog)
and it does not work either although all related files were created properly.
What's weird: I can not see any change in the state file if I populate the
input log file with some testing data even after Rsyslog restart using
# systemctl restart rsyslog (it should update the state file by default).
Just to point out: the imjournal and imuxsock plugins work and populate the fallback log file /tmp/rsyslog-testing.log correctly. Also
manually running Rsyslog on foreground with -D and/or -d options
did not helped me much to clarify why the imfile plugin does not work
for me in this particular configuration.
So, could you please
check my RainerScript syntax whether there is no obvious fault (I guess there is no such),
show me some working imfile plugin configuration on EL7?
Thank you very much.
--
mjf
With a few minor changes it finaly started to work properly. I think the
main root cause of the problem in my case must have been my testing it in
the /tmp directory where Rsyslog does not seem to work properly for some
reason on CentOS 7.
(May it be the /tmp is populated by the File System Namespace even
despite the fact that Systemd option PrivateTmp is not set to true in
the Rsyslog unit file and this option should be set to false by
default according to the Systemd manual page? This is higly unprobable, but
I haven't managed myself to dig more further into it yet. If I find it out,
I will update this answer.)
The other minor cause might have been incorrect filter written in
RainerScript (my real testing instance contained a horrible typo I
simply over-looked). So here is the resulting testing configuration that
works like charm for me.
# cat /etc/rsyslog.conf
global(
workDirectory = "/var/lib/rsyslog"
)
module(
load = "imuxsock"
)
module(
load = "imjournal"
stateFile = "journal.state"
)
module(
load = "imfile"
pollingInterval = "10"
)
ruleset(name = "test-ruleset") {
if $programname == "test-syslogtag" then {
action(
type = "omfile"
file = "/var/log/test-file.log"
)
stop
}
}
input(
type = "imfile"
tag = "test-syslogtag:"
stateFile = "test-input.state"
facility = "daemon"
severity = "debug"
file = "/var/log/test-input.in"
ruleset = "test-ruleset"
)
if prifilt("*.*") then {
action(
type = "omfile"
file = "/var/log/rsyslog-testing.log"
)
}
A little hint for those not knowing it - the $syslogtag and the
$programname seem to be close relatives: $syslogtag := $programname ":".
You can easily find out all the $ prefixed variables you can match against
by using RSYSLOG_DebugFormat output template which is already compiled in.
I hope it helps.
--
mjf
I've been coding for a while and moving from IDE to IDE is a real pain when what I need most is just ctag and code completion. I finally decided to go to vim, well neovim in this case but that's beside the point.
I have ctags working and was following this tutorial from the YCM site along with this one
but I can't seem to get YCM to work for me.
I followed these step:
cd ~/.nvim/bundle
git clone https://github.com/Valloric/YouCompleteMe.git
cd YouCompleteMe
git submodule update --init --recursive
./install.sh --clang-completer --system-libclang
this went through downloaded, compiled, installed some thing
Then I created the .ycm_extra_conf.py file at "~/.nvim/.ycm_extra_conf.py"
and added: let g:ycm_global_ycm_extra_conf = "~/.nvim/.ycm_extra_conf.py"
to the top of my ~/.nvimrc file
This is what I added to my .ycm_extra_conf.py file
# This file is NOT licensed under the GPLv3, which is the license for the rest
# of YouCompleteMe.
#
# Here's the license text for this file:
#
# This is free and unencumbered software released into the public domain.
#
# Anyone is free to copy, modify, publish, use, compile, sell, or
# distribute this software, either in source code form or as a compiled
# binary, for any purpose, commercial or non-commercial, and by any
# means.
#
# In jurisdictions that recognize copyright laws, the author or authors
# of this software dedicate any and all copyright interest in the
# software to the public domain. We make this dedication for the benefit
# of the public at large and to the detriment of our heirs and
# successors. We intend this dedication to be an overt act of
# relinquishment in perpetuity of all present and future rights to this
# software under copyright law.
#
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
# EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
# MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
# IN NO EVENT SHALL THE AUTHORS BE LIABLE FOR ANY CLAIM, DAMAGES OR
# OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
# ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
# OTHER DEALINGS IN THE SOFTWARE.
#
# For more information, please refer to <http://unlicense.org/>
import os
import ycm_core
# These are the compilation flags that will be used in case there's no
# compilation database set (by default, one is not set).
# CHANGE THIS LIST OF FLAGS. YES, THIS IS THE DROID YOU HAVE BEEN LOOKING FOR.
flags = [
'-Wall',
'-Wextra',
'-Werror',
'-Wno-long-long',
'-Wno-variadic-macros',
'-fexceptions',
'-DNDEBUG',
'-ftrapv',
'-finstrument’-functions',
'-Wfloat’-equal',
'-Wundef',
'-Wshadow',
'-Wpointer-arith',
'-Wcast’-align',
'-Wstrict-prototypes',
'-Wstrict-overflow=5',
'-Wwrite-strings',
'-Waggregate-return',
'-Wcast-qual',
'-Wswitch-default',
'-Wswitch-enum',
'-Wconversion',
'-Wunreachable-code',
# You 100% do NOT need -DUSE_CLANG_COMPLETER in your flags; only the YCM
# source code needs it.
'-DUSE_CLANG_COMPLETER',
# THIS IS IMPORTANT! Without a "-std=<something>" flag, clang won't know which
# language to use when compiling headers. So it will guess. Badly. So C++
# headers will be compiled as C headers. You don\'t want that so ALWAYS specify
# a "-std=<something>".
# For a C project, you would set this to something like 'c99' instead of
# 'c99'.
'-std=c+99',
# ...and the same thing goes for the magic -x option which specifies the
# language that the files to be compiled are written in. This is mostly
# relevant for c headers.
'-x',
'c',
'-isystem',
'../BoostParts',
'-isystem',
# This path will only work on OS X, but extra paths that don't exist are not harmful
'/System/Library/Frameworks/Python.framework/Headers',
'-isystem',
'../llvm/include',
'-isystem',
'../llvm/tools/clang/include',
'-I',
'.',
'-I',
'./ClangCompleter',
'-isystem',
'./tests/gmock/gtest',
'-isystem',
'./tests/gmock/gtest/include',
'-isystem',
'./tests/gmock',
'-isystem',
'./tests/gmock/include',
]
# Set this to the absolute path to the folder (NOT the file!) containing the
# compile_commands.json file to use that instead of 'flags'. See here for
# more details: http://clang.llvm.org/docs/JSONCompilationDatabase.html
#
# You can get CMake to generate this file for you by adding:
# set( CMAKE_EXPORT_COMPILE_COMMANDS 1 )
# to your CMakeLists.txt file.
#
# Most projects will NOT need to set this to anything; you can just change the
# 'flags' list of compilation flags. Notice that YCM itself uses that approach.
compilation_database_folder = ''
if os.path.exists( compilation_database_folder ):
database = ycm_core.CompilationDatabase( compilation_database_folder )
else:
database = None
SOURCE_EXTENSIONS = [ '.cpp', '.cxx', '.cc', '.c', '.m', '.mm' ]
def DirectoryOfThisScript():
return os.path.dirname( os.path.abspath( __file__ ) )
def MakeRelativePathsInFlagsAbsolute( flags, working_directory ):
if not working_directory:
return list( flags )
new_flags = []
make_next_absolute = False
path_flags = [ '-isystem', '-I', '-iquote', '--sysroot=' ]
for flag in flags:
new_flag = flag
if make_next_absolute:
make_next_absolute = False
if not flag.startswith( '/' ):
new_flag = os.path.join( working_directory, flag )
for path_flag in path_flags:
if flag == path_flag:
make_next_absolute = True
break
if flag.startswith( path_flag ):
path = flag[ len( path_flag ): ]
new_flag = path_flag + os.path.join( working_directory, path )
break
if new_flag:
new_flags.append( new_flag )
return new_flags
def IsHeaderFile( filename ):
extension = os.path.splitext( filename )[ 1 ]
return extension in [ '.h', '.hxx', '.hpp', '.hh' ]
def GetCompilationInfoForFile( filename ):
# The compilation_commands.json file generated by CMake does not have entries
# for header files. So we do our best by asking the db for flags for a
# corresponding source file, if any. If one exists, the flags for that file
# should be good enough.
if IsHeaderFile( filename ):
basename = os.path.splitext( filename )[ 0 ]
for extension in SOURCE_EXTENSIONS:
replacement_file = basename + extension
if os.path.exists( replacement_file ):
compilation_info = database.GetCompilationInfoForFile(
replacement_file )
if compilation_info.compiler_flags_:
return compilation_info
return None
return database.GetCompilationInfoForFile( filename )
def FlagsForFile( filename, **kwargs ):
if database:
# Bear in mind that compilation_info.compiler_flags_ does NOT return a
# python list, but a "list-like" StringVec object
compilation_info = GetCompilationInfoForFile( filename )
if not compilation_info:
return None
final_flags = MakeRelativePathsInFlagsAbsolute(
compilation_info.compiler_flags_,
compilation_info.compiler_working_dir_ )
else:
relative_to = DirectoryOfThisScript()
final_flags = MakeRelativePathsInFlagsAbsolute( flags, relative_to )
return {
'flags': final_flags,
'do_cache': True
}
I have a project where I created ctags and I'm able to get around the file in vim using it's ctags support but, code completion just isn't working.
I went through the steps, went inside my ~/.nvim/bundle
This error was caused by typos in my .ycm_extras file
I run :YcmDebugInfo
and I get this error that my server has crashed:
Printing YouCompleteMe debug information...
-- Server crashed, no debug info from server
-- Server running at: http://127.0.0.1:64594
-- Server process ID: 47040
-- Server logfiles:
-- /var/folders/64/d3t4_pcs06943d651dfgp3m00000gn/T/ycm_temp/server_64594_stdout.log
-- /var/folders/64/d3t4_pcs06943d651dfgp3m00000gn/T/ycm_temp/server_64594_stderr.log
reading the stderr log I saw that I had some of these "\xe2" characters in my .ycm_extra_conf.py file.
Running a python script from this answer, I found the culprits.
I first changed to the proper directory where the .ycm_extra file was located then ran python:
Brother:.vim blubee$ python
Python 2.7.6 (default, Sep 9 2014, 15:04:36)
[GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.39)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> with open(".ycm_extra_conf.py") as fp:
... for i, line in enumerate(fp):
... if "\xe2" in line:
... print i, repr(line)
...
45 "'-finstrument\xe2\x80\x99-functions',\n"
46 "'-Wfloat\xe2\x80\x99-equal',\n"
50 "'-Wcast\xe2\x80\x99-align',\n"
removing the quote marks fixed the problem, now YCM works just as expected.
you can see the file before:
'-finstrument’-functions',
'-Wfloat’-equal',
'-Wundef',
'-Wshadow',
'-Wpointer-arith',
'-Wcast’-align',
and after:
'-finstrument-functions', #removed quote after finstrument
'-Wfloat-equal', #removed quote after Wfloat
'-Wundef',
'-Wshadow',
'-Wpointer-arith',
'-Wcast-align', #removed quote after Wcast
I want to develop a simple C application for learning purposes using Eclipse (Juno) CDT.
For that, I created the sample project provided in the IDE that creates a simple Hello World executable.
But when I want to build the project, the following errors comes up:
make: all
make: Error -- Could not find configuration file /etc/startup.mk
What does this mean? I can't find a file named like this anywhere on my system. Curiously enough, it works on my OS X with the same setup perfectly. Just not on my Windows machine.
What is going wrong here?
Edit: make -V show the following output:
D:\>make -V
make - Version 7.0 build 1182
Built-in Rules (cannot be changed):
OS:=NT
.IMPORT .IGNORE : ROOTDIR
.MAKEFILES:makefile
.SOURCE : .NULL
#B = $(#:b)
#D = $(#:d)
#F = $(#:f)
%B = $(%:b)
%D = $(%:d)
%F = $(%:f)
*B = $(*:b)
*D = $(*:d)
*F = $(*:f)
<B = $(<:b)
<D = $(<:d)
<F = $(<:f)
?B = $(?:b)
?F = $(?:f)
?D = $(?:d)
System Configuration:
SWITCHAR = /
OSVERSION = 01
OSRELEASE = 5
DIRSEPSTR = /\:
SHELL = /mksnt/sh.exe
SHELLFLAGS = /c
SHELLMETAS =
GROUPSHELL = /mksnt/sh.exe
GROUPFLAGS =
GROUPSUFFIX =
MAKEDIR = D:/
PWD = D:/
The make executable that is in your path is not the GNU make that eclipse expects and needs. It is probably a tool that comes with some other product -- make is a pretty common name. If your windows is not too old, you could try where make to locate the culprit and remove it from your path. Once you have done that, eclipse will be able to the GNU make by itself if you used the standard installation of your toolchain, or you could add it to your path. Alternatively, you can customize the eclipse build settings and explicitly point it to the make you want to use.
The make you want is probably in C:\MinGW\msys\1.0\bin, but could be somewhere else depending on how you installed the toolchain. There is also a mingw32-make in C:\MinGW\bin -- all assuming that you are using MinGW