Hey, Sorry to barge in again but another problem that we are facing while trying to use the autoconf/msys solution is the following:
make all-recursive make[1]: Entering directory `/home/aserdean/2_12_2013/openvswitch' Making all in datapath make[2]: Entering directory `/home/aserdean/2_12_2013/openvswitch/datapath' make[3]: Entering directory `/home/aserdean/2_12_2013/openvswitch/datapath' make[3]: Nothing to be done for `all-am'. make[3]: Leaving directory `/home/aserdean/2_12_2013/openvswitch/datapath' make[2]: Leaving directory `/home/aserdean/2_12_2013/openvswitch/datapath' make[2]: Entering directory `/home/aserdean/2_12_2013/openvswitch' source='lib/aes128.c' object='lib/aes128.obj' libtool=no \ DEPDIR=.deps depmode=none /bin/sh ./build-aux/depcomp \ ./build-aux/cccl -DHAVE_CONFIG_H -I. -I ./windows -I ./windows/thirdpa rty/pthreads/include -I ./include -I ./lib -I ./lib -Wstrict-prototypes -Wall -Wextra -Wno-sign-compare -Wpointer-arith -Wdeclaration-after-statement -Wformat -security -Wno-format-zero-length -Wswitch-enum -Wunused-parameter -Wstrict-alia sing -Wbad-function-cast -Wcast-align -Wstrict-prototypes -Wold-style-definition -Wmissing-prototypes -Wmissing-field-initializers -Wthread-safety -g -c -o lib /aes128.obj `echo 'lib/aes128.c'` cl -nologo -EHsc -DHAVE_CONFIG_H -I. -I ./windows -I ./windows/thirdparty/pthrea ds/include -I ./include -I ./lib -I ./lib -Zi -c -Folib/aes128.obj lib/aes128.c aes128.c rm -f lib/libopenvswitch.a ar cru lib/libopenvswitch.a lib/aes128.obj lib/backtrace.obj lib/bfd.obj lib/bit map.obj lib/bond.obj lib/bundle.obj lib/byteq.obj lib/cfm.obj lib/classifier.obj lib/command-line.obj lib/coverage.obj lib/crc32c.obj lib/csum.obj lib/daemon.ob j lib/dummy.obj lib/dpif-netdev.obj lib/dpif.obj lib/heap.obj lib/dynamic-string .obj lib/entropy.obj lib/fatal-signal.obj lib/flow.obj lib/guarded-list.obj lib/ hash.obj lib/hindex.obj lib/hmap.obj lib/hmapx.obj lib/jhash.obj lib/json.obj li b/jsonrpc.obj lib/lacp.obj lib/latch.obj lib/learn.obj lib/learning-switch.obj l ib/list.obj lib/lockfile.obj lib/mac-learning.obj lib/match.obj lib/memory.obj l ib/meta-flow.obj lib/multipath.obj lib/netdev-dummy.obj lib/netdev-vport.obj lib /netdev.obj lib/netlink.obj lib/nx-match.obj lib/odp-execute.obj lib/odp-util.ob j lib/ofp-actions.obj lib/ofp-errors.obj lib/ofp-msgs.obj lib/ofp-parse.obj lib/ ofp-print.obj lib/ofp-util.obj lib/ofp-version-opt.obj lib/ofpbuf.obj lib/ovs-at omic-gcc4+.obj lib/ovs-atomic-pthreads.obj lib/ovs-thread.obj lib/ovsdb-data.obj lib/ovsdb-error.obj lib/ovsdb-idl.obj lib/ovsdb-parser.obj lib/ovsdb-types.obj lib/packets.obj lib/pcap-file.obj lib/poll-loop.obj lib/process.obj lib/random.o bj lib/rconn.obj lib/reconnect.obj lib/seq.obj lib/sha1.obj lib/shash.obj lib/si map.obj lib/signals.obj lib/smap.obj lib/socket-util.obj lib/sort.obj lib/sset.o bj lib/stp.obj lib/stream-fd.obj lib/stream-tcp.obj lib/stream-unix.obj lib/stre am.obj lib/string.obj lib/svec.obj lib/table.obj lib/tag.obj lib/timer.obj lib/t imeval.obj lib/token-bucket.obj lib/unicode.obj lib/unixctl.obj lib/util.obj lib /uuid.obj lib/vconn-stream.obj lib/vconn.obj lib/vlan-bitmap.obj lib/vlandev.obj lib/vlog.obj lib/vswitch-idl.obj lib/vtep-idl.obj lib/async-append-null.obj lib/stream-nossl.obj lib/dirs.obj ranlib lib/libopenvswitch.a rm -f lib/libsflow.a ar cru lib/libsflow.a lib/lib_libsflow_a-sflow_agent.obj lib/lib_libsflow_a-sflo w_sampler.obj lib/lib_libsflow_a-sflow_poller.obj lib/lib_libsflow_a-sflow_recei ver.obj ranlib lib/libsflow.a CCCL is not using the Visual Sutdio compiler to link togheter a windows static library(.lib) it is using the GNU one and generating a Unix specific(*.a). This in the end might turn out to be a problem. Probably CCCL can be extended so that there will be no mismatch between the archives and the way they are generated. The last update for CCCL was in 2003 and probably has not been updated/maintained. The next problem I am facing with this build system is the following: ./build-aux/cccl -Wstrict-prototypes -Wall -Wextra -Wno-sign-compare -Wpointer-a rith -Wdeclaration-after-statement -Wformat-security -Wno-format-zero-length -Ws witch-enum -Wunused-parameter -Wstrict-aliasing -Wbad-function-cast -Wcast-align -Wstrict-prototypes -Wold-style-definition -Wmissing-prototypes -Wmissing-field -initializers -Wthread-safety -g -o utilities/ovs-appctl.exe utilities/ovs-ap pctl.obj lib/libopenvswitch.a link -nologo -out:utilities/ovs-appctl.exe utilities/ovs-appctl.obj lib/libopenv switch.a link: invalid option -- n Try `link --help' for more information. make[2]: *** [utilities/ovs-appctl.exe] Error 1 make[2]: Leaving directory `/home/aserdean/2_12_2013/openvswitch' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/aserdean/2_12_2013/openvswitch' make: *** [all] Error 2 Probably either the arguments or the format the linker is called is not proper. One should investigate this further :). Kind Regards, Alin. ________________________________________ From: dev-boun...@openvswitch.org [dev-boun...@openvswitch.org] on behalf of Ben Pfaff [b...@nicira.com] Sent: Tuesday, November 26, 2013 6:23 PM To: Alessandro Pilotti Cc: dev@openvswitch.org Subject: Re: [ovs-dev] Autoconf limits on Windows On Tue, Nov 26, 2013 at 10:46:36AM +0000, Alessandro Pilotti wrote: > > > On 26/nov/2013, at 08:10, "Ben Pfaff" <b...@nicira.com> wrote: > > > > Since you're OK with manual updates, I'm happy in principle with having > > IDE-related files in the repository as long as they are not unreasonably > > large. But there's something weird going on. Why would special files > > would be needed for syntax highlighting or Git integration or even > > integrated debugging? Other editors and IDEs manage these features > > without special files (I often use these features in Emacs). > > Visual Studio unfortunately does not work with Makefiles, nor it's > able to import a project from them. It can run a Makefile based > project, but that's almost useless. But why does is a "project" needed just for editing features? > > I guess by "CI gate" you mean something preventing checking into the > > repository until basic tests pass? We haven't implemented anything like > > that, yet. We expect developers to run "make check" before applying > > commits. On a normal dev box (such as the 2-year-old laptop I'm typing > > this on) this takes under a minute. It isn't really practical to expect > > a dev to do this on multiple OSes, though, so we'd need something more > > sophisticated if we were to attempt this for Windows. > > > > Are you familiar by any chance with how Gerrit / Jenkins / SmokeStack > work on OpenStack? We're not using Gerrit: http://benpfaff.org/writings/gerrit.html _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
_______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
